From issues at jboss.org Wed Mar 1 01:14:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 1 Mar 2017 01:14:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8265) Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context In-Reply-To: References: Message-ID: Ondrej Lukas created WFLY-8265: ---------------------------------- Summary: Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context Key: WFLY-8265 URL: https://issues.jboss.org/browse/WFLY-8265 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Quoting from [1]: {quote} DEBUG [org.wildfly.security] (default task-1) Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory "com.sun.jndi.ldap.LdapCtxFactory" from classloader ModuleClassLoader for Module "deployment.print-roles.war" from Service Module Loader [Root exception is java.lang.ClassNotFoundException: "com.sun.jndi.ldap.LdapCtxFactory" from [Module "deployment.print-roles.war" from Service Module Loader]] at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120) at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) We can see from the stack trace the deployments class loader is being used. I think by default the ClassLoader of the subsystem should be used i.e. that will have the common dependencies. However we may want to also add a module attribute so an alternative module can be specified for when creating the InitialDirContext. {quote} [1] https://issues.jboss.org/browse/JBEAP-8025?focusedCommentId=13370291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13370291 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 01:44:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 1 Mar 2017 01:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-957) Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370640#comment-13370640 ] Martin Choma commented on ELY-957: ---------------------------------- On read there have to be ensured correct/fresh data is picked up by: - synchronized keyword - volatile keyword Current implementation DefaultSingleSignOnEntry choose volatile approach. It is correct. My concern is that all future implementation of SingleSignOnEntry must think on that and use volatile approach to be correct. On the other hand if DefaultSingleSignOn.getIdentity use synchronized keyword, all future implementation will be safe. Does it make sense to you? >From my PoV moving synchronized modifier to synchronized block, doesn't change situation. > Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized > ---------------------------------------------------------------------------- > > Key: ELY-957 > URL: https://issues.jboss.org/browse/ELY-957 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Paul Ferraro > Priority: Minor > > Coverity static-analysis scan found getter is not synchronized, while setter is. > {code} > public SecurityIdentity getIdentity() { > return this.entry.getCachedIdentity().getSecurityIdentity(); > } > {code} > Current implementation is correct because in DefaultSingleSignOnEntry (currently only avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile. > However other implementations can be wrongly implemented. Once getIdentity() would be marked with synchronize modifier, such problem shouldn't occure. > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490896&defectInstanceId=2123245&mergedDefectId=1396940 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 03:23:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Wed, 1 Mar 2017 03:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8257) Ignore failing test in AS TS with Elytron profile to be able to run -Delytron on pull requests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370659#comment-13370659 ] Josef Cacek commented on WFLY-8257: ----------------------------------- PR sent. It adds `assumes` to failing tests. To reenable them without code chage one may use the `-Dwildfly.tmp.enable.elytron.profile.tests=true` Maven argument. > Ignore failing test in AS TS with Elytron profile to be able to run -Delytron on pull requests > ---------------------------------------------------------------------------------------------- > > Key: WFLY-8257 > URL: https://issues.jboss.org/browse/WFLY-8257 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Critical > > Introduce similar assumption method as is already present for failing invocation tests in {{DisableInvocationTestUtil}}. Use it for tests failing with Elytron profile to be able to run the pull request checks with {{-Delytron}} too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 03:32:00 2017 From: issues at jboss.org (Radim Hatlapatka (JIRA)) Date: Wed, 1 Mar 2017 03:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBEE-174) Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370665#comment-13370665 ] Radim Hatlapatka commented on JBEE-174: --------------------------------------- [~ctomc] sounds good to me. > Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable > ----------------------------------------------------------------------- > > Key: JBEE-174 > URL: https://issues.jboss.org/browse/JBEE-174 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-el-api > Affects Versions: jboss-el-api_3.0_spec-1.0.7.Final > Reporter: Masafumi Miura > Assignee: Tomaz Cerar > Fix For: jboss-el-api_3.0_spec-1.0.8.Final > > > [UEL-38|https://java.net/jira/browse/UEL-38] introduced an EL 2.2 backward compatible switch {{"javax.el.bc2.2"}}. However, it's currently unable to enable this in EAP 7. Improve this and expose this properly via configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 05:20:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Wed, 1 Mar 2017 05:20:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2347) FileArgumentTestCase from WF-core fails intermittently on IPv6 In-Reply-To: References: Message-ID: Jean-Francois Denise created WFCORE-2347: -------------------------------------------- Summary: FileArgumentTestCase from WF-core fails intermittently on IPv6 Key: WFCORE-2347 URL: https://issues.jboss.org/browse/WFCORE-2347 Project: WildFly Core Issue Type: Bug Components: CLI, Test Suite Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Some tests FileArgumentTestCase and FileWithPropertiesTestCase are making use of a private way to interact with a CLI process. We know that this inter-process communication is subject to timing issues. I suspect these intermittent failures to be caused by this private implementation. A lot of effort has been put in the class CliProcessWrapper to stabilise this interaction. These 2 tests should use this class. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 05:21:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Wed, 1 Mar 2017 05:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8265) Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski reassigned WFLY-8265: ---------------------------------------- Assignee: Bartosz Baranowski (was: Darran Lofthouse) > Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context > ------------------------------------------------------------------------------------------------ > > Key: WFLY-8265 > URL: https://issues.jboss.org/browse/WFLY-8265 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Bartosz Baranowski > Priority: Critical > > Quoting from [1]: > {quote} > DEBUG [org.wildfly.security] (default task-1) Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory "com.sun.jndi.ldap.LdapCtxFactory" from classloader ModuleClassLoader for Module "deployment.print-roles.war" from Service Module Loader [Root exception is java.lang.ClassNotFoundException: "com.sun.jndi.ldap.LdapCtxFactory" from [Module "deployment.print-roles.war" from Service Module Loader]] > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) > We can see from the stack trace the deployments class loader is being used. > I think by default the ClassLoader of the subsystem should be used i.e. that will have the common dependencies. However we may want to also add a module attribute so an alternative module can be specified for when creating the InitialDirContext. > {quote} > [1] https://issues.jboss.org/browse/JBEAP-8025?focusedCommentId=13370291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13370291 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 07:16:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 1 Mar 2017 07:16:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication trigger SSLSession renegotiation? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-621: --------------------------------- Priority: Blocker (was: Major) > Client Cert authentication trigger SSLSession renegotiation? > ------------------------------------------------------------ > > Key: ELY-621 > URL: https://issues.jboss.org/browse/ELY-621 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta28 > > > This could be an option to enable demanding client verification for an established connection but depending on the application being accessed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 07:20:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 1 Mar 2017 07:20:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2193) JmxControlledStateNotificationsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated WFCORE-2193: ------------------------------ Description: *org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase* {{cd testsuite/domain/}} {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} *org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase* {{cd testsuite/manualmode/}} {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} Both test cases fail with: {code} Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE! - in org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.007 sec <<< FAILURE! java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},"rolled-back" => true}}}}}}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.setup(JMXFacadeListenerDeploymentSetupTask.java:75) at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.setupDomain(JmxControlledStateNotificationsTestCase.java:66) org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.014 sec <<< FAILURE! java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found"}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found","rolled-back" => true}}}}}}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.tearDown(JMXFacadeListenerDeploymentSetupTask.java:115) at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.tearDownDomain(JmxControlledStateNotificationsTestCase.java:71) {code} was: *org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase* {{cd testsuite/domain/}} {{mvn test -DtestLogToFile -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} *org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase* {{cd testsuite/manualmode/}} {{mvn test -DtestLogToFile -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} Both test cases fail with: {code} Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE! - in org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.007 sec <<< FAILURE! java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},"rolled-back" => true}}}}}}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.setup(JMXFacadeListenerDeploymentSetupTask.java:75) at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.setupDomain(JmxControlledStateNotificationsTestCase.java:66) org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.014 sec <<< FAILURE! java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found"}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found","rolled-back" => true}}}}}}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.tearDown(JMXFacadeListenerDeploymentSetupTask.java:115) at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.tearDownDomain(JmxControlledStateNotificationsTestCase.java:71) {code} > JmxControlledStateNotificationsTestCase fails with security manager in WF core > ------------------------------------------------------------------------------ > > Key: WFCORE-2193 > URL: https://issues.jboss.org/browse/WFCORE-2193 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ingo Weiss > Fix For: 3.0.0.Alpha23 > > > *org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase* > {{cd testsuite/domain/}} > {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} > *org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} > Both test cases fail with: > {code} > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE! - in org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase > org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.007 sec <<< FAILURE! > java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},"rolled-back" => true}}}}}}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) > at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) > at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.setup(JMXFacadeListenerDeploymentSetupTask.java:75) > at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.setupDomain(JmxControlledStateNotificationsTestCase.java:66) > org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.014 sec <<< FAILURE! > java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found"}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found","rolled-back" => true}}}}}}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) > at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) > at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.tearDown(JMXFacadeListenerDeploymentSetupTask.java:115) > at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.tearDownDomain(JmxControlledStateNotificationsTestCase.java:71) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 07:20:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 1 Mar 2017 07:20:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2193) JmxControlledStateNotificationsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated WFCORE-2193: ------------------------------ Environment: IBM JDK > JmxControlledStateNotificationsTestCase fails with security manager in WF core > ------------------------------------------------------------------------------ > > Key: WFCORE-2193 > URL: https://issues.jboss.org/browse/WFCORE-2193 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Environment: IBM JDK > Reporter: Jan Tymel > Assignee: Ingo Weiss > Fix For: 3.0.0.Alpha23 > > > *org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase* > {{cd testsuite/domain/}} > {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} > *org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} > Both test cases fail with: > {code} > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE! - in org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase > org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.007 sec <<< FAILURE! > java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},"rolled-back" => true}}}}}}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) > at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) > at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.setup(JMXFacadeListenerDeploymentSetupTask.java:75) > at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.setupDomain(JmxControlledStateNotificationsTestCase.java:66) > org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.014 sec <<< FAILURE! > java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found"}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found","rolled-back" => true}}}}}}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) > at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) > at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.tearDown(JMXFacadeListenerDeploymentSetupTask.java:115) > at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.tearDownDomain(JmxControlledStateNotificationsTestCase.java:71) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 07:21:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 1 Mar 2017 07:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2193) JmxControlledStateNotificationsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reopened WFCORE-2193: ------------------------------- Reopening due to the issue with IBM JDK. The test located in domain submodule of testsuite fails with IBM JDK. On OpenJDK and "standard" (~Oracle) JDK passes. The output is following: {code} [Server:main-one] 13:07:49,343 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR12-core/testsuite/domain/target/domains/JmxControlledStateNotificationsTestCase/master" "read")" in code source "(vfs:/content/test-jmx-notifications-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-notifications-deployment.jar" from Service Module Loader") [Server:main-one] at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) [Server:main-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] [Server:main-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] [Server:main-one] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] [Server:main-one] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR12-core/testsuite/domain/target/domains/JmxControlledStateNotificationsTestCase/master" "read")" in code source "(vfs:/content/test-jmx-notifications-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-notifications-deployment.jar" from Service Module Loader") [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta25-redhat-1.jar:1.1.0.Beta25-redhat-1] [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta25-redhat-1.jar:1.1.0.Beta25-redhat-1] [Server:main-one] at java.lang.SecurityManager.checkRead(SecurityManager.java:901) [rt.jar:1.8.0] [Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350) [wildfly-elytron-1.1.0.Beta25-redhat-1.jar:1.1.0.Beta25-redhat-1] [Server:main-one] at sun.nio.fs.UnixPath.checkRead(UnixPath.java:815) [rt.jar:1.8.0] [Server:main-one] at sun.nio.fs.UnixFileSystemProvider.checkAccess(UnixFileSystemProvider.java:302) [rt.jar:1.8.0] [Server:main-one] at java.nio.file.Files.createDirectories(Files.java:757) [rt.jar:1.8.0] [Server:main-one] at org.wildfly.test.jmx.ControlledStateNotificationListener.init(ControlledStateNotificationListener.java:57) [Server:main-one] at org.wildfly.test.jmx.ControlledStateNotificationListener.(ControlledStateNotificationListener.java:43) [Server:main-one] at java.lang.J9VMInternals.newInstanceImpl(Native Method) [vm.jar:1.8.0] [Server:main-one] at java.lang.Class.newInstance(Class.java:1899) [vm.jar:1.8.0] [Server:main-one] at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:106) [Server:main-one] ... 5 more [Server:main-one] [Server:main-one] 13:07:49,353 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 7) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "test-jmx-notifications-deployment.jar")]) - failure description: { [Server:main-one] "WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.io.FilePermission\" \"/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR12-core/testsuite/domain/target/domains/JmxControlledStateNotificationsTestCase/master\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar\" from Service Module Loader\") [Server:main-one] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.io.FilePermission\" \"/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR12-core/testsuite/domain/target/domains/JmxControlledStateNotificationsTestCase/master\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar\" from Service Module Loader\")"}, [Server:main-one] "WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"] [Server:main-one] } [Server:main-one] 13:07:49,365 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 7) WFLYSRV0021: Deploy of deployment "test-jmx-notifications-deployment.jar" was rolled back with the following failure message: [Server:main-one] { [Server:main-one] "WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.io.FilePermission\" \"/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR12-core/testsuite/domain/target/domains/JmxControlledStateNotificationsTestCase/master\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar\" from Service Module Loader\") [Server:main-one] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.io.FilePermission\" \"/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR12-core/testsuite/domain/target/domains/JmxControlledStateNotificationsTestCase/master\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar\" from Service Module Loader\")"}, [Server:main-one] "WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"] [Server:main-one] } [Server:main-one] 13:07:49,369 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment test-jmx-notifications-deployment.jar (runtime-name: test-jmx-notifications-deployment.jar) in 11ms [Server:main-one] 13:07:49,377 INFO [org.jboss.as.controller] (ServerService Thread Pool -- 7) WFLYCTL0183: Service status report [Server:main-one] WFLYCTL0186: Services which failed to start: service test.deployment.jmx [Server:main-one] Failed: { "address" => [ ("server-group" => "main-server-group"), ("deployment" => "test-jmx-notifications-deployment.jar") ], "operation" => "add", "enabled" => true } {code} The test located in manualmode submodule passes fine on all JDKs. > JmxControlledStateNotificationsTestCase fails with security manager in WF core > ------------------------------------------------------------------------------ > > Key: WFCORE-2193 > URL: https://issues.jboss.org/browse/WFCORE-2193 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Environment: IBM JDK > Reporter: Jan Tymel > Assignee: Ingo Weiss > Fix For: 3.0.0.Alpha23 > > > *org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase* > {{cd testsuite/domain/}} > {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} > *org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}} > Both test cases fail with: > {code} > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE! - in org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase > org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.007 sec <<< FAILURE! > java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},"rolled-back" => true}}}}}}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) > at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) > at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.setup(JMXFacadeListenerDeploymentSetupTask.java:75) > at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.setupDomain(JmxControlledStateNotificationsTestCase.java:66) > org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.014 sec <<< FAILURE! > java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found"}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found","rolled-back" => true}}}}}}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115) > at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100) > at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.tearDown(JMXFacadeListenerDeploymentSetupTask.java:115) > at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.tearDownDomain(JmxControlledStateNotificationsTestCase.java:71) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 08:11:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 1 Mar 2017 08:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-846) Some tests throws "Permission check failed" while run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reopened WFCORE-846: ------------------------------ Reopening since there still are some tests failing with security manager: * org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase * org.jboss.as.test.integration.domain.suites.DeploymentRolloutFailureTestCase * org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase * org.jboss.as.test.integration.logging.operations.CustomFormattersTestCase * org.jboss.as.test.integration.logging.operations.CustomHandlerOperationsTestCase * org.jboss.as.test.integration.logging.operations.CustomHandlerTestCase * org.jboss.as.test.integration.logging.operations.Log4jCustomHandlerTestCase * org.jboss.as.test.integration.logging.perdeploy.JBossLog4jXmlTestCase * org.jboss.as.test.integration.logging.perdeploy.JBossLoggingPropertiesTestCase * org.jboss.as.test.integration.logging.perdeploy.Log4jPropertiesTestCase * org.jboss.as.test.integration.logging.perdeploy.Log4jXmlTestCase * org.jboss.as.test.integration.logging.perdeploy.LoggingPropertiesTestCase * org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase * org.jboss.as.test.integration.logging.profiles.NonExistingProfileTestCase * org.jboss.as.test.integration.logging.syslog.SyslogHandlerTestCase * org.jboss.as.test.integration.management.cli.modules.ModuleResourceRootPathsTestCase * org.jboss.as.test.integration.mgmt.access.JmxSensitiveTestCase * org.jboss.as.test.manualmode.deployment.InterdependentDeploymentTestCase * org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase * org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase * org.jboss.as.test.manualmode.logging.PerDeployLoggingTestCase * org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase * org.jboss.as.test.manualmode.logging.SizeAppenderRestartTestCase * org.jboss.as.test.manualmode.logging.SyslogIsNotAvailableDuringServerBootTestCase * org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase > Some tests throws "Permission check failed" while run with security manager > --------------------------------------------------------------------------- > > Key: WFCORE-846 > URL: https://issues.jboss.org/browse/WFCORE-846 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.Alpha11 > Reporter: Petr Kremensky > Assignee: Ingo Weiss > Fix For: 3.0.0.Alpha23 > > > Some tests are failing to deploy an archive when testsuite run with security manager enabled. > {noformat} > 08:03:07,171 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service test.deployment.trivial: org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > 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" "test.deployment.trivial.prop" "write")" in code source "(vfs:/content/test-http-deployment.sar )" of "null") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:274) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:176) > at java.lang.System.setProperty(System.java:792) > at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:80) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 08:03:07,173 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-5) WFLYCTL0013: Operation ("add") failed - address: ([{"deployment" => "test-http-deployment.sar"}]) - failure description: {"WFLYCTL0080: Failed services" => {"test.deployment.trivial" => "org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"test.deployment.trivial.prop\" \"write\")\" in code source \"(vfs:/content/test-http-deployment.sar )\" of \"null\")"}} > 08:03:07,174 ERROR [org.jboss.as.server] (XNIO-1 task-5) WFLYSRV0021: Deploy of deployment "test-http-deployment.sar" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"test.deployment.trivial" => "org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"test.deployment.trivial.prop\" \"write\")\" in code source \"(vfs:/content/test-http-deployment.sar )\" of \"null\")"}} > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 08:14:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 1 Mar 2017 08:14:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8266) Credential store, during creation of CS backed keystore is not created on filesystem. In-Reply-To: References: Message-ID: Martin Choma created WFLY-8266: ---------------------------------- Summary: Credential store, during creation of CS backed keystore is not created on filesystem. Key: WFLY-8266 URL: https://issues.jboss.org/browse/WFLY-8266 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical Keystore is created after writing secret key into it. So instead of "write alias" operation it is more "write alias and create backed keystore if not exists yet" operation. How to reproduce: - create credential store from scratch {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.config.dir) {"outcome" => "success"} {code} - myCredStore.jceks does not exists on FS (I would expect it will be created) {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore/alias=myAlias:add(secret-value=secret) {"outcome" => "success"} {code} - myCredStore.jceks exists on FS Setting high priority as lack of this ehaviour can lead to more complex problems in multiprocess scenarios (e.g domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 08:15:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 1 Mar 2017 08:15:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8266) Credential store, during creation of CS backed keystore is not created on filesystem. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFLY-8266: ------------------------------- Description: Keystore is created after writing secret key into it. So instead of "write alias" operation it is more "write alias and create backed keystore if not exists yet" operation. How to reproduce: - create credential store from scratch {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.config.dir) {"outcome" => "success"} {code} - myCredStore.jceks does not exists on FS (I would expect it will be created) {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore/alias=myAlias:add(secret-value=secret) {"outcome" => "success"} {code} - myCredStore.jceks exists on FS Setting high priority as lack of this behaviour can lead to more complex problems in multiprocess scenarios (e.g domain mode) was: Keystore is created after writing secret key into it. So instead of "write alias" operation it is more "write alias and create backed keystore if not exists yet" operation. How to reproduce: - create credential store from scratch {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.config.dir) {"outcome" => "success"} {code} - myCredStore.jceks does not exists on FS (I would expect it will be created) {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore/alias=myAlias:add(secret-value=secret) {"outcome" => "success"} {code} - myCredStore.jceks exists on FS Setting high priority as lack of this ehaviour can lead to more complex problems in multiprocess scenarios (e.g domain mode) > Credential store, during creation of CS backed keystore is not created on filesystem. > ------------------------------------------------------------------------------------- > > Key: WFLY-8266 > URL: https://issues.jboss.org/browse/WFLY-8266 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > Keystore is created after writing secret key into it. So instead of "write alias" operation it is more "write alias and create backed keystore if not exists yet" operation. > How to reproduce: > - create credential store from scratch > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.config.dir) > {"outcome" => "success"} > {code} > - myCredStore.jceks does not exists on FS (I would expect it will be created) > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore/alias=myAlias:add(secret-value=secret) > {"outcome" => "success"} > {code} > - myCredStore.jceks exists on FS > Setting high priority as lack of this behaviour can lead to more complex problems in multiprocess scenarios (e.g domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:05:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Wed, 1 Mar 2017 09:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370905#comment-13370905 ] Sunil kondkar commented on HAWKULARQE-32: ----------------------------------------- Test case in Polarion: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10033 > Cassandra/Hawkular Schema Test > ------------------------------ > > Key: HAWKULARQE-32 > URL: https://issues.jboss.org/browse/HAWKULARQE-32 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Test case request from Heiko (verbatim): > Start C*,wait until up. Start metrics/h-services > and once it starts schema creation (watch the logs), kill C*. Stop > h-services. Start C* again and then h-services,it should continue Schema > creation > While I was talking about h-services here, this applies foremost to > h-metrics (which is also used inside > of h-services). > Also I think Juca had a variation of this yesterday: > deploy h-metrics + C* into Openshift and then scale h-metrics up and > down at will. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:05:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 1 Mar 2017 09:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-978) MechanismInformationCallback blocks certificate based authn (Undertow with Elytron) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek closed ELY-978. ---------------------------- Resolution: Won't Fix Not a bug. {{CLIENT_CERT}} mechanism name has to used in {{http-authentication-factory}} instead of {{CLIENT-CERT}}. [~zrhoads], could you fix the documentation [1] please? > MechanismInformationCallback blocks certificate based authn (Undertow with Elytron) > ----------------------------------------------------------------------------------- > > Key: ELY-978 > URL: https://issues.jboss.org/browse/ELY-978 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Beta26 > Reporter: Ondrej Kotek > Priority: Blocker > Labels: authentication, eap71_alpha, http, ssl > Attachments: deployment.war, standalone.xml > > > It is not possible to set up authentication based on certificates. Following the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything works as expected until a client with {{client}} certificate tries to access protected resource that should be accessible. Such resource returns 403 Forbidden instead of 200 OK. Trace log: > {noformat} > 13:31:15,565 TRACE [org.wildfly.security] (default task-33) Evidence verification: evidence = org.wildfly.security.evidence.X509PeerCertificateChainEvidence at 42d7e114 evidencePrincipal = CN=client > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) X500 principal [CN=client] decoded as name [client] (attribute values: [client]) > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post realm rewritten: [client], realm rewritten: [client] > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) X500 principal [CN=client] decoded as name [client] (attribute values: [client]) > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Evidence verification succeed for alias [client] > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [Guest, Admin] > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authorizing principal client. > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authorizing against the following attributes: [] => [] > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Permission mapping: identity [client] with roles [Guest, Admin] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authorization succeed > 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authentication succeed for principal [CN=client] > 13:31:15,573 TRACE [org.wildfly.security] (default task-34) Handling MechanismInformationCallback > 13:31:15,574 TRACE [org.wildfly.security] (default task-34) java.lang.IllegalStateException: ELY01119: Unable to resolve MechanismConfiguration for mechanismType='HTTP', mechanismName='CLIENT_CERT', hostName='localhost', protocol='https'. > {noformat} > The last message comes from {{ServerAuthenticationContext}} [3]. > [1] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#UsingtheElytronSubsystem-EnableTwoWaySSL%2FTLSinWildFlyforApplications > [2] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#UsingtheElytronSubsystem-ConfigureAuthenticationwithCertificates > [3] https://github.com/wildfly-security/wildfly-elytron/blob/6e4dad322ab0421522979448ea18801c2832791c/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L904 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:14:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Wed, 1 Mar 2017 09:14:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370914#comment-13370914 ] Sunil kondkar commented on HAWKULARQE-32: ----------------------------------------- Tested manually as below: 1) create/start cassandra version 3.10 ccm create hawkular -v 3.10 -n 1 ccm updateconf "start_rpc: true" ccm start 2) Start hawkular service version 33 ./standalone.sh -Dhawkular.rest.user=jdoe -Dhawkular.rest.password=password -Dhawkular.agent.enabled=true 3) Stopped cassandra with 'ccm stop' when I see below in logs 08:03:14,852 INFO [org.hawkular.metrics.schema.SchemaService] (metricsservice-lifecycle-thread) Creating table metrics_tags_idx 08:03:16,038 INFO [org.hawkular.metrics.schema.SchemaService] (metricsservice-lifecycle-thread) Creating table metrics_idx 4) Stopped hawkular services 5) Started cassandra with ccm start 6) Verified hawkular service continues schema creation. > Cassandra/Hawkular Schema Test > ------------------------------ > > Key: HAWKULARQE-32 > URL: https://issues.jboss.org/browse/HAWKULARQE-32 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Test case request from Heiko (verbatim): > Start C*,wait until up. Start metrics/h-services > and once it starts schema creation (watch the logs), kill C*. Stop > h-services. Start C* again and then h-services,it should continue Schema > creation > While I was talking about h-services here, this applies foremost to > h-metrics (which is also used inside > of h-services). > Also I think Juca had a variation of this yesterday: > deploy h-metrics + C* into Openshift and then scale h-metrics up and > down at will. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:18:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 09:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370917#comment-13370917 ] Scott Marlow commented on WFLY-5319: ------------------------------------ [https://github.com/wildfly/wildfly/pull/8092] mentions "WFLY-5319 ignore TxTimeoutTestCase which seems to fail due to EJB StatefulSessionSynchronizationInterceptor.releaseLock not expecting to be called from TM Reaper thread", since I didn't mention this claim here, of what the possible cause is, I'm repeating it now. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:25:01 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Wed, 1 Mar 2017 09:25:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370936#comment-13370936 ] Tomas Hofman commented on WFLY-8238: ------------------------------------ This is a bug in messaging subsystem - {{AlternativeAttributeCheckHandler}} doesn't allow to undefine attributes where alternatives are set, if the alternatives are undefined. It should take into account whether the attribute is required or not, which it doesn't and treats them always as required. When this is changed it will affect number of other attributes across the subsystem, and for some the "required" behaviour may be desirable. I didn't find any attributes that would be marked as required and had alternatives set too, which is probably a mistake. > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:26:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Wed, 1 Mar 2017 09:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8267) Unable to undefine credential-reference In-Reply-To: References: Message-ID: Tomas Hofman created WFLY-8267: ---------------------------------- Summary: Unable to undefine credential-reference Key: WFLY-8267 URL: https://issues.jboss.org/browse/WFLY-8267 Project: WildFly Issue Type: Bug Components: JMS, Security Reporter: Tomas Hofman Assignee: Tomas Hofman A bridge is added and a credential-reference is set. However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. Also neither credential-reference and password are required=true, so they may be undefined. {code} /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) { "outcome" => "failed", "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, "rolled-back" => true } {code} The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference {code} /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) { "outcome" => "failed", "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, "rolled-back" => true } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:40:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 09:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370956#comment-13370956 ] Scott Marlow commented on WFLY-5319: ------------------------------------ Adding some more notes on this: Note 1: {quote} I noticed that [1] TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest is now failing on the CI machine but not locally for me. I saved a copy of the test output [1], so that we could look at the possible causes. 1. Reaper thread throws a IllegalMonitorStateException from org.jboss.as.ejb3.tx.OwnableReentrantLock.unlock(). I'm not sure exactly why but I'm wondering if TransactionSynchronizationRegistry.getTransactionKey() returned null to StatefulSessionSynchronizationInterceptor.getLockOwner(), which causes the current "thread" to be used in the call to OwnableReentrantLock.unlock(). This happens at "21:06:34,782" 2. An exception is thrown in the application thread and the EJB container ends the transaction ("javax.ejb.EJBTransactionRolledbackException: Transaction rolled back" is thrown since the transaction is already rolled back). 3. Application thread fails unit test with "entity manager should not of been closed by the reaper thread" error. From the log, the entity manager is closed from the reaper thread at "21:06:34,782". The unit test failure is reported from the application thread at "21:06:34,800". The test failure is clearly caused by (3) but that might reflect that the application thread was first disassociated from the active transaction and then the reaper thread ran the JPA container afterCompletion() synchronization callback (which is now legal but not expected IMO). {quote} Note 2, which refers back to note 1: {quote} I looked a little closer at (2) and the exception call stack points to the code at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) which is: else if (txStatus == Status.STATUS_ROLLEDBACK) { tm.rollback(); throw EjbLogger.ROOT_LOGGER.transactionAlreadyRolledBack(tx); } I don't really have any questions about (2), that is how the EJB container informs the application of the failure. For (1), I am curious if TransactionSynchronizationRegistry.getTransactionKey() can be expected to return null when the reaper thread calls the afterCompletion sync callback? For (3), it seems likely that the application thread was first disassociated from the transaction and then the JPA afterCompletion was invoked, which (properly) closed the container managed entity manager. If this is what happened, then TxTimeoutTestCase needs to check for different conditions to detect (potential) concurrency failure. {quote} > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:41:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Wed, 1 Mar 2017 09:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370959#comment-13370959 ] Sunil kondkar commented on HAWKULARQE-32: ----------------------------------------- verified with docker start/stop cassandra and hawkular service containers manually. hawkular services continues schema creation if interrupted during initial install Test Run: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%2058%2DDR3 > Cassandra/Hawkular Schema Test > ------------------------------ > > Key: HAWKULARQE-32 > URL: https://issues.jboss.org/browse/HAWKULARQE-32 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Test case request from Heiko (verbatim): > Start C*,wait until up. Start metrics/h-services > and once it starts schema creation (watch the logs), kill C*. Stop > h-services. Start C* again and then h-services,it should continue Schema > creation > While I was talking about h-services here, this applies foremost to > h-metrics (which is also used inside > of h-services). > Also I think Juca had a variation of this yesterday: > deploy h-metrics + C* into Openshift and then scale h-metrics up and > down at will. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:43:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Wed, 1 Mar 2017 09:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar resolved HAWKULARQE-32. ------------------------------------- Resolution: Done > Cassandra/Hawkular Schema Test > ------------------------------ > > Key: HAWKULARQE-32 > URL: https://issues.jboss.org/browse/HAWKULARQE-32 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Test case request from Heiko (verbatim): > Start C*,wait until up. Start metrics/h-services > and once it starts schema creation (watch the logs), kill C*. Stop > h-services. Start C* again and then h-services,it should continue Schema > creation > While I was talking about h-services here, this applies foremost to > h-metrics (which is also used inside > of h-services). > Also I think Juca had a variation of this yesterday: > deploy h-metrics + C* into Openshift and then scale h-metrics up and > down at will. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:54:01 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 1 Mar 2017 09:54:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8268) Obtain password from external source (CMD, EXT) doesn't work on Windows. In-Reply-To: References: Message-ID: Hynek ?v?bek created WFLY-8268: ---------------------------------- Summary: Obtain password from external source (CMD, EXT) doesn't work on Windows. Key: WFLY-8268 URL: https://issues.jboss.org/browse/WFLY-8268 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Now you add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 09:54:02 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 1 Mar 2017 09:54:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8268) Obtain password from external source (CMD, EXT) doesn't work on Windows. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFLY-8268: ------------------------------- Description: Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 Because when I add there back slashed to path then it works. was: Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Now you add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 Because when I add there back slashed to path then it works. > Obtain password from external source (CMD, EXT) doesn't work on Windows. > ------------------------------------------------------------------------ > > Key: WFLY-8268 > URL: https://issues.jboss.org/browse/WFLY-8268 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Obtain password from external source (CMD, EXT) doesn't work on Windows. > Try to create new CS which obtains password from external source: > {code} > /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) > pass.bat file contains only this > {code} > echo %1 > {code} > Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: > Add new alias to CS -> JCEKS file is created > Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. > In my opinion there is problem with back slashes in script path. > https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 > Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:04:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 1 Mar 2017 10:04:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: Bela Ban created JGRP-2161: ------------------------------ Summary: UNICAST3: message delivery fails after disconnect-connect sequence Key: JGRP-2161 URL: https://issues.jboss.org/browse/JGRP-2161 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 4.1, 4.0.1 When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:08:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 1 Mar 2017 10:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370983#comment-13370983 ] Bela Ban commented on JGRP-2161: -------------------------------- The test passes in JGroups 4.0.0.Beta3 > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:08:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 1 Mar 2017 10:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370983#comment-13370983 ] Bela Ban edited comment on JGRP-2161 at 3/1/17 10:07 AM: --------------------------------------------------------- The test passes in JGroups 4.0.0.Beta3, but fails in 4.0.0.CR1, so this is a regression between Beta3 and CR1. was (Author: belaban): The test passes in JGroups 4.0.0.Beta3 > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:12:01 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 1 Mar 2017 10:12:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8269) Encrypt-protocol can not be used without Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9225 to WFLY-8269: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8269 (was: JBEAP-9225) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: (was: 7.1.0.DR12) Affects Testing: (was: Regression) > Encrypt-protocol can not be used without Elytron > ------------------------------------------------ > > Key: WFLY-8269 > URL: https://issues.jboss.org/browse/WFLY-8269 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > When we tried to configure UDP stack in JGroups subsystem, we added ASYM_ENCRYPT protocol. According to the model definition attributes "key-store" and "key-alias" together with "credential-reference" child element had to be defined as well. Due to this configuration server failed to start with errors: > {code} > ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT' are not available: > org.wildfly.security.key-store.server.keystore; There are no known registration points which can provide this capability. > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > We should still be able to define original protocol behaviour without Elytron, but it seems we can not use encrypt-protocol without keystore definition in Elytron which could be a backward compatibility issue. > Used configuration in standalone-ha.xml is attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:23:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 1 Mar 2017 10:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8270) UndertowSslSecurityDomainTestCase - close client to avoid resource leaks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek moved JBEAP-9226 to WFLY-8270: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8270 (was: JBEAP-9226) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR12) > UndertowSslSecurityDomainTestCase - close client to avoid resource leaks > ------------------------------------------------------------------------ > > Key: WFLY-8270 > URL: https://issues.jboss.org/browse/WFLY-8270 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > > There are 4 tests in https://github.com/wildfly/wildfly/blob/master/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowSslSecurityDomainTestCase.java#L122 and each is creating client and making the call. > But the client is never closed. > I checked https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/Utils.java#L397 but it doesn't close the client either. > I think it makes sense to enhance those 4 tests with {{client.close();}} lines. > Changing Utils class can cause regressions when client is used for multiple calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:25:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 1 Mar 2017 10:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371001#comment-13371001 ] Brian Stansberry commented on WFLY-8238: ---------------------------------------- [~thofman] I haven't looked at the code involved here at all, but just as an FYI -- we only added overall validation of requires and alternatives into the kernel in the last couple years. (See ValidateModelStepHandler in WildFly Core.) So since that didn't exist for years, there's a fair amount of custom validation code scattered around the code base from when devs saw a particular need for some validation check. When you find that kind of thing, and it sounds like you have here, it's best to investigate with the component lead whether the validation is meant to do anything different from what the kernel now does. If it isn't, strongly consider stripping it out and relying on the kernel. > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 10:35:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 1 Mar 2017 10:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the jboss-logging-annotations dependency from the core feature pack. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reassigned WFCORE-1965: ------------------------------------- Assignee: James Perkins (was: Darran Lofthouse) > Remove the jboss-logging-annotations dependency from the core feature pack. > --------------------------------------------------------------------------- > > Key: WFCORE-1965 > URL: https://issues.jboss.org/browse/WFCORE-1965 > Project: WildFly Core > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: James Perkins > Priority: Critical > Fix For: 3.0.0.Beta7 > > > This was added inadvertently with some other changes: - > {noformat} > > org.jboss.logging > jboss-logging-annotations > > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 11:56:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 11:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Marlow updated WFLY-5319: ------------------------------- Attachment: server.zip > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 12:01:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 12:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371099#comment-13371099 ] Scott Marlow commented on WFLY-5319: ------------------------------------ Attached server.log which is from following steps: 1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class: {quote} @Ignore // WFLY-5319 is for fixing this test {quote} 2. Change into folder testsuite/integration/basic 3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure: {quote} test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE! java.lang.AssertionError: transaction was canceled by reaper thread at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173) {quote} See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 12:12:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 1 Mar 2017 12:12:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371100#comment-13371100 ] Bela Ban commented on JGRP-2161: -------------------------------- git bisect shows the offending commit to be {{509cfe}}; this is where {{message_processing_policy}} in the transport was set to "max" (from "submit") as default. Changing this back to "max" fixes the issue. The problem is that {{MaxOneThreadPerSender}} creates message batches for each sender's address in its table and uses the batches to queue messages when a message for a given sender is already being processed. However, the dest and sender's address of those batches is not changed on a disconnect-connect sequence, which results in messages being sent to old UUIDs, which are discarded by the transport logic when comparing the destination address of a batch with the local address. A simple solution is to remove entries from that table on a disconnect and on a view change (remove entries for left members). > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 12:13:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 12:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371099#comment-13371099 ] Scott Marlow edited comment on WFLY-5319 at 3/1/17 12:12 PM: ------------------------------------------------------------- Attached server.log which is from following steps: 1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class: {quote} @Ignore // WFLY-5319 is for fixing this test {quote} 2. Change into folder testsuite/integration/basic 3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure: {quote} ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase Tests run: 3, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 3.866 sec <<< FAILURE! - in org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE! java.lang.AssertionError: transaction was canceled by reaper thread at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173) Results : Failed tests: TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest:173 transaction was canceled by reaper thread {quote} See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else. was (Author: smarlow): Attached server.log which is from following steps: 1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class: {quote} @Ignore // WFLY-5319 is for fixing this test {quote} 2. Change into folder testsuite/integration/basic 3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure: {quote} test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE! java.lang.AssertionError: transaction was canceled by reaper thread at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173) {quote} See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 12:39:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 12:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371109#comment-13371109 ] Scott Marlow commented on WFLY-5319: ------------------------------------ Just challenging myself and my assertion in the negativeTxTimeoutVerifyReaperThreadCanceledTxTest method. Current code is: {code} /** * Repeat the same test as test_negativeTxTimeoutTest but also ensure that the reaper thread canceled the tx. * If this test fails, it could be that the tx reaper thread name changed or we are using a different tx manager. * * @throws Exception */ // @Ignore // WFLY-5319 is for fixing this test (see failure https://gist.github.com/scottmarlow/6409290362f35f2d1320) @Test @InSequence(3) public void test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest() throws Exception { TestEntityManager.clearState(); assertFalse("entity manager state is not reset", TestEntityManager.getClosedByReaperThread()); SFSB1 sfsb1 = lookup("ejbjar/SFSB1", SFSB1.class); try { sfsb1.createEmployeeWaitForTxTimeout(true, "Wily", "1 Appletree Lane", 10); } catch (Exception e) { // ignore the tx rolled back exception // } assertFalse("entity manager should not of been closed by the reaper thread", TestEntityManager.getClosedByReaperThread()); assertTrue("transaction was canceled by reaper thread", SFSB1.isAfterCompletionCalledByTMTimeoutThread()); } {code} We are failing the second assertion "assertTrue("transaction was canceled by reaper thread", SFSB1.isAfterCompletionCalledByTMTimeoutThread())". I am trying to get more information out of this test case by recording the thread name of which the afterCompletion was called from (should be the reaper thread or application thread. Once we have the thread name from the failing case, we can determine next steps to update the test. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 13:01:01 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Wed, 1 Mar 2017 13:01:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-982) Filtering properties for EXTERNAL SASL mechanism differs from Oracle implementaion In-Reply-To: References: Message-ID: Josef Cacek created ELY-982: ------------------------------- Summary: Filtering properties for EXTERNAL SASL mechanism differs from Oracle implementaion Key: ELY-982 URL: https://issues.jboss.org/browse/ELY-982 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse SASL mechanism filtering in Elytron {{ExternalSasl*}} factories differs from Oracle one. http://docs.oracle.com/javase/jndi/tutorial/ldap/security/sasl.html Oracle has EXTERNAL mechanism valid for policies: * javax.security.sasl.policy.noplaintext * javax.security.sasl.policy.noactive * javax.security.sasl.policy.nodictionary Elytron factories doesn't allow EXTERNAL mechanism for these filtering properties set to true. [~dlofthouse] If the changed filtering policy is intentional, please reject this issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 13:31:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 1 Mar 2017 13:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371129#comment-13371129 ] Scott Marlow commented on WFLY-5319: ------------------------------------ [https://mail.google.com/mail/u/0/#search/label%3Apullrequests+org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase/14fb7a37d6e43d47] shows that the failure in our CI testing was: {quote} org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest: java.lang.AssertionError: entity manager should not of been closed by the reaper thread at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:197) {quote} It is probably more important to test that the entity manager is not invoked by multiple threads, than whether the application thread attempts to end the transaction before the reaper thread or reaper thread before app thread. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 13:36:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Wed, 1 Mar 2017 13:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-983) WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods In-Reply-To: References: Message-ID: Josef Cacek created ELY-983: ------------------------------- Summary: WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods Key: ELY-983 URL: https://issues.jboss.org/browse/ELY-983 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse The description of {{MECHANISM_QUERY_ALL}} filtering property says: {quote} This flag is only effective on calls to SaslServerFactory.getMechanismNames(Map) or SaslClientFactory.getMechanismNames(Map) for Elytron-provided SASL factories. {quote} It's not true for EXTERNAL SASL mechanism factories, where it's taken into account also in {{createSaslServer/Client}} methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 14:17:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 1 Mar 2017 14:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-957) Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371160#comment-13371160 ] Paul Ferraro commented on ELY-957: ---------------------------------- [~mchoma] The purpose of moving the synchronized modifier to an internal synchronized block is not meant to change the behavior - just the signature of the public methods. I'm not sure what you mean by "future implementations" being safe. The DefaultSingleSignOn and DefaultSingleSignOnEntry objects are an implementation detail of the DefaultSingleSignOnManager implementation. Any implementation of SingleSignOnManager is free to enforce whatever threading constraints it wants/needs. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/http/util/sso/DefaultSingleSignOnManager.java > Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized > ---------------------------------------------------------------------------- > > Key: ELY-957 > URL: https://issues.jboss.org/browse/ELY-957 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Paul Ferraro > Priority: Minor > > Coverity static-analysis scan found getter is not synchronized, while setter is. > {code} > public SecurityIdentity getIdentity() { > return this.entry.getCachedIdentity().getSecurityIdentity(); > } > {code} > Current implementation is correct because in DefaultSingleSignOnEntry (currently only avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile. > However other implementations can be wrongly implemented. Once getIdentity() would be marked with synchronize modifier, such problem shouldn't occure. > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490896&defectInstanceId=2123245&mergedDefectId=1396940 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 14:25:00 2017 From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=) Date: Wed, 1 Mar 2017 14:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1459) Question mark (?) triggers invalid name error in execution and validation In-Reply-To: References: Message-ID: M?lanie Gauthier created DROOLS-1459: ---------------------------------------- Summary: Question mark (?) triggers invalid name error in execution and validation Key: DROOLS-1459 URL: https://issues.jboss.org/browse/DROOLS-1459 Project: Drools Issue Type: Bug Components: dmn engine Reporter: M?lanie Gauthier Assignee: Edson Tirelli But it is a valid character in name, it is added by rule 30 of FEEL grammar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 14:38:00 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Wed, 1 Mar 2017 14:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371166#comment-13371166 ] Claudio Miranda commented on WFLY-6607: --------------------------------------- As the PR is merged, I think this issue may be resolved as done. > Broadcast/Discovery group is possible to create with just a name > ---------------------------------------------------------------- > > Key: WFLY-6607 > URL: https://issues.jboss.org/browse/WFLY-6607 > Project: WildFly > Issue Type: Bug > Components: JMS, Web Console > Affects Versions: 10.0.0.Final > Reporter: Chen Maoqian > Assignee: Chen Maoqian > > When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default > user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one) > At this moment it's possible to create broadcast group with just a name which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 15:01:01 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Wed, 1 Mar 2017 15:01:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1459) Question mark (?) triggers invalid name error in execution and validation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371180#comment-13371180 ] Edson Tirelli commented on DROOLS-1459: --------------------------------------- You are correct, I missed that `?` can be used as a starting character for variable names. > Question mark (?) triggers invalid name error in execution and validation > ------------------------------------------------------------------------- > > Key: DROOLS-1459 > URL: https://issues.jboss.org/browse/DROOLS-1459 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: M?lanie Gauthier > Assignee: Edson Tirelli > > But it is a valid character in name, it is added by rule 30 of FEEL grammar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 18:11:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 1 Mar 2017 18:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7778) Remoting EJB identity propagation does not work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFLY-7778: ----------------------------- Summary: Remoting EJB identity propagation does not work with Elytron (was: Remoting identity propagation does not work with Elytron) > Remoting EJB identity propagation does not work with Elytron > ------------------------------------------------------------ > > Key: WFLY-7778 > URL: https://issues.jboss.org/browse/WFLY-7778 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron-legacy-test-fails > > Even througth succesful obtaining LoginContext, identity is not propagated in EJB call. > Identity is unauthorized on server side. > *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference. > Often error message: > {code:java} > SaslException: Authentication failed: all available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 19:07:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 1 Mar 2017 19:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-37) Batching logging profile creation CLI commands can cause errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFCORE-37: -------------------------------- Workaround Description: Combine command #3 and #4: {noformat} /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add(handlers=[myHandler]) {noformat} was: Combine command #3 and #4: {noformat} /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add(handlers=[handler=myHandler]) {noformat} > Batching logging profile creation CLI commands can cause errors > --------------------------------------------------------------- > > Key: WFCORE-37 > URL: https://issues.jboss.org/browse/WFCORE-37 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > > Given these set of commands: > {noformat} > /subsystem=logging/logging-profile=myLoggingProfile:add > /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"}) > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler) > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO) > {noformat} > If I run those in a batch, I get an error: > {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([ > ("subsystem" => "logging"), > ("logging-profile" => "myLoggingProfile"), > ("root-logger" => "ROOT") > ]) - failure description: "JBAS011536: Handler myHandler is already assigned." > {noformat} > If I run each one individually, I get no error. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 21:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 1 Mar 2017 21:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2342) CLI can't connect to DC on native port without defined remote protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2342: ------------------------------------- Fix Version/s: 3.0.0.Beta7 > CLI can't connect to DC on native port without defined remote protocol > ---------------------------------------------------------------------- > > Key: WFCORE-2342 > URL: https://issues.jboss.org/browse/WFCORE-2342 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Remoting, Security > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Blocker > Labels: cli, regression, remoting, ssl > Fix For: 3.0.0.Beta7 > > > CLI is able to connect to DC to native port (9999) only when protocol _remote_ is specified. It is regression, EAP 7.0.0.GA is able to connect when no protocol is defined or with _remoting_ and _remote_ (maybe some others). > EAP 7.0.0.GA > {noformat} > msimka at msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 > [domain at 127.0.0.1:9999 /] quit > msimka at msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999 > [domain at 127.0.0.1:9999 /] quit > msimka at msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999 > [domain at 127.0.0.1:9999 /] quit > {noformat} > EAP 7.1.0.DR12 > {noformat} > msimka at msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 > Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999 > msimka at msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999 > Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999 > msimka at msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999 > [domain at 127.0.0.1:9999 /] quit > {noformat} > Stacktrace from attached jboss-cli.log > {noformat} > 15:46:26,184 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? > at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) > at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) > at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) > at org.xnio.ssl.JsseStreamConduit.performIO(JsseStreamConduit.java:1364) > at org.xnio.ssl.JsseStreamConduit.read(JsseStreamConduit.java:991) > at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) > at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:165) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:160) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:446) > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:468) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 21:26:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 1 Mar 2017 21:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFLY-7462. ------------------------------------ Assignee: Brian Stansberry (was: Darran Lofthouse) Resolution: Done > Do not log common CLI failures for Elytron to server log > -------------------------------------------------------- > > Key: WFLY-7462 > URL: https://issues.jboss.org/browse/WFLY-7462 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Critical > Labels: user_experience > Fix For: 11.0.0.Alpha1 > > > Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means: > * trying to add duplicate service -> ERROR in server log > * missing required attribute of any resource attribute in CLI command -> ERROR in server log > * missing capability -> ERROR in server log > * ... > Some reasons why these logs should not be logged to server log: > * Adding useless messages to server log. > * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing. > These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 22:41:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Wed, 1 Mar 2017 22:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1459) Question mark (?) triggers invalid name error in execution and validation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371278#comment-13371278 ] Edson Tirelli commented on DROOLS-1459: --------------------------------------- The problem was actually that there was another Lexer rule clashing with the identifier's rule. Fixed. PR submitted. https://github.com/droolsjbpm/kie-dmn/pull/50 > Question mark (?) triggers invalid name error in execution and validation > ------------------------------------------------------------------------- > > Key: DROOLS-1459 > URL: https://issues.jboss.org/browse/DROOLS-1459 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: M?lanie Gauthier > Assignee: Edson Tirelli > > But it is a valid character in name, it is added by rule 30 of FEEL grammar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:00:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 02:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7593) JspTagTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFLY-7593: ----------------------------------- Assignee: Ivo Studensky (was: Jan Tymel) > JspTagTestCase fails with security manager > ------------------------------------------ > > Key: WFLY-7593 > URL: https://issues.jboss.org/browse/WFLY-7593 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.jsp.JspTagTestCase#test* > {{./integration-tests.sh -DtestLogToFile=false -Dtest=JspTagTestCase -Dsecurity.manager}} > {code} > ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /ed26af0c-bc91-49ea-b6c3-196d33e8de5a/index2.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ )" of "org.apache.jasper.servlet.JasperLoader at a7277ba2") > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$425.00000000C40C2470.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(AccessController.java:650) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ )" of "org.apache.jasper.servlet.JasperLoader at a7277ba2") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.Class.getClassLoader(Class.java:442) > at org.jboss.as.weld.injection.InjectionTargets.createInjectionTarget(InjectionTargets.java:63) > at org.jboss.as.weld.deployment.WeldClassIntrospector.getInjectionTarget(WeldClassIntrospector.java:90) > at org.jboss.as.weld.deployment.WeldClassIntrospector.createInstance(WeldClassIntrospector.java:102) > at org.jboss.as.ee.component.ComponentRegistry.createInstance(ComponentRegistry.java:85) > at org.jboss.as.web.common.WebInjectionContainer.newInstance(WebInjectionContainer.java:77) > at org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager.newInstance(UndertowJSPInstanceManager.java:75) > at org.apache.jsp.index2_jsp._jspx_meth_my_005ftag_005f0(index2_jsp.java:128) > at org.apache.jsp.index2_jsp._jspService(index2_jsp.java:99) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) > ... 48 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:00:01 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 02:00:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7594) FlushOperationsTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFLY-7594: ----------------------------------- Assignee: Ivo Studensky > FlushOperationsTestCase fails with security manager > --------------------------------------------------- > > Key: WFLY-7594 > URL: https://issues.jboss.org/browse/WFLY-7594 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase#flushAllConnectionsInPool* > *org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase#flushGracefullyConnectionsInPool* > *org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase#flushIdleConnectionsInPool* > *org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase#flushInvalidConnectionsInPool* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=FlushOperationsTestCase -Dsecurity.manager}} > {code} > SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase.flushAllConnectionsInPool: java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:0" "listen,resolve")" in code source "(vfs:/content/flush-operations.jar )" of "ModuleClassLoader for Module "deployment.flush-operations.jar:main" from Service Module Loader") > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase.executeAndAssertSuccess(FlushOperationsTestCase.java:301) > at org.jboss.as.test.integration.jca.flushing.FlushOperationsTestCase.cleanup(FlushOperationsTestCase.java:152) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) > at org.jboss.arquillian.container.test.impl.execution.AfterLifecycleEventExecuter.on(AfterLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.testenricher.cdi.CreationalContextDestroyer.destory(CreationalContextDestroyer.java:44) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:243) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:219) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > 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.net.SocketPermission" "localhost:0" "listen,resolve")" in code source "(vfs:/content/flush-operations.jar )" of "ModuleClassLoader for Module "deployment.flush-operations.jar:main" 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.SecurityManager.checkListen(SecurityManager.java:1131) > at org.wildfly.security.manager.WildFlySecurityManager.checkListen(WildFlySecurityManager.java:392) > at sun.nio.ch.SocketChannelImpl.bind(SocketChannelImpl.java:582) > at sun.nio.ch.SocketAdaptor.bind(SocketAdaptor.java:135) > at org.xnio.nio.WorkerThread.openTcpStreamConnection(WorkerThread.java:263) > at org.xnio.XnioIoThread.openStreamConnection(XnioIoThread.java:237) > at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:342) > at org.xnio.http.HttpUpgrade$HttpUpgradeState.doUpgrade(HttpUpgrade.java:247) > at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$100(HttpUpgrade.java:165) > at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:112) > at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:110) > at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:201) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:487) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:410) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:406) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:166) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > ... 139 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:00:04 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 02:00:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7595) JaxrsJacksonProviderTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFLY-7595: ----------------------------------- Assignee: Ivo Studensky > JaxrsJacksonProviderTestCase fails with security manager > -------------------------------------------------------- > > Key: WFLY-7595 > URL: https://issues.jboss.org/browse/WFLY-7595 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testDurationJsr310* > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testDurationJsrjdk8* > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testJacksonWithJsonIgnore* > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testSimpleJacksonResource* > {{./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dts.noSmoke -Dtest=JaxrsJacksonProviderTestCase -Dsecurity.manager}} > {code} > ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /jaxrsnoap/myjaxrs/country: java.lang.RuntimeException: RESTEASY003920: Unable to instantiate ContextResolver > at org.jboss.resteasy.spi.ResteasyProviderFactory.processProviderContracts(ResteasyProviderFactory.java:1480) > at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1304) > at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1256) > at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1178) > at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:601) > at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:377) > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:252) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250) > at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:171) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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.lang.RuntimeException: RESTEASY003325: Failed to construct public org.jboss.as.test.integration.jaxrs.jackson.JacksonProducer() throws java.lang.Exception > at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) > at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:1964) > at org.jboss.resteasy.spi.ResteasyProviderFactory.addContextResolver(ResteasyProviderFactory.java:1019) > at org.jboss.resteasy.spi.ResteasyProviderFactory.processProviderContracts(ResteasyProviderFactory.java:1474) > ... 52 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/opt/jboss-eap/src/7.1/jboss-eap-7.1.0.DR8/dist/target/jboss-eap-7.1/modules/system/layers/base/com/fasterxml/jackson/datatype/jackson-datatype-jdk8/main/jackson-datatype-jdk8-2.8.3.redhat-1.jar" "read")" in code source "(vfs:/content/jaxrsnoap.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.jaxrsnoap.war:main" 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.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350) > at java.util.zip.ZipFile.(ZipFile.java:210) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at java.util.jar.JarFile.(JarFile.java:103) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) > at java.net.URL.openStream(URL.java:1045) > at java.util.ServiceLoader.parse(ServiceLoader.java:304) > at java.util.ServiceLoader.access$200(ServiceLoader.java:185) > at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357) > at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398) > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > at com.fasterxml.jackson.databind.ObjectMapper.findModules(ObjectMapper.java:963) > at com.fasterxml.jackson.databind.ObjectMapper.findModules(ObjectMapper.java:946) > at com.fasterxml.jackson.databind.ObjectMapper.findAndRegisterModules(ObjectMapper.java:982) > at org.jboss.as.test.integration.jaxrs.jackson.JacksonProducer.(JacksonProducer.java:44) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > ... 55 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:01:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 02:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7737) MDB and BMT timeout tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFLY-7737: ----------------------------------- Assignee: Ivo Studensky > MDB and BMT timeout tests fail with security manager > ---------------------------------------------------- > > Key: WFLY-7737 > URL: https://issues.jboss.org/browse/WFLY-7737 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase#noTimeout* > *org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase#resetTimeoutToDefault* > *org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase#timeout* > *org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase#timeoutMultiple* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=StatelessTimeoutTestCase -Dsecurity.manager}} > {noformat} > ERROR [org.jboss.as.ejb3.invocation] (pool-3-thread-1) WFLYEJB0034: EJB Invocation failed on component StatelessBmtBean for method public java.lang.String org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessBmtBean.testTransaction(int,int) throws java.rmi.RemoteException,javax.naming.NamingException,javax.transaction.SystemException: javax.ejb.EJBException: java.lang.RuntimeException: java.lang.ExceptionInInitializerError > at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:85) > at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91) > at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106) > at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:456) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) > at org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessBmtBean$$$view1.testTransaction(Unknown Source) > at org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase.timeoutMultiple(StatelessTimeoutTestCase.java:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:243) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:219) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > 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.lang.RuntimeException: java.lang.ExceptionInInitializerError > ... 193 more > Caused by: java.lang.ExceptionInInitializerError > at org.jboss.as.test.integration.transactions.TxTestUtil.(TxTestUtil.java:42) > at org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessBmtBean.testTransaction(StatelessBmtBean.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:456) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:85) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:96) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103) > ... 190 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/stateless-btm-txn-timeout.jar )" of "ModuleClassLoader for Module "deployment.stateless-btm-txn-timeout.jar:main" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) > at java.lang.System.getProperty(System.java:717) > at java.lang.Integer.getInteger(Integer.java:1101) > at java.lang.Integer.getInteger(Integer.java:1057) > at org.jboss.as.test.shared.TimeoutUtil.(TimeoutUtil.java:39) > ... 208 more > {noformat} > *org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase#noTimeout* > *org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase#transactionTimeoutActivationProperty* > *org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase#transactionTimeoutAnnotation* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=MessageDrivenTimeoutTestCase -Dsecurity.manager}} > {noformat} > ERROR [org.jboss.as.ejb3.invocation] (Thread-0 (ActiveMQ-client-global-threads-982415698)) WFLYEJB0034: EJB Invocation failed on component AnnotationTimeoutMDB for method public void org.jboss.as.test.integration.ejb.transaction.mdb.timeout.AnnotationTimeoutMDB.onMessage(javax.jms.Message): javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:456) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) > at org.jboss.as.test.integration.ejb.transaction.mdb.timeout.AnnotationTimeoutMDB$$$view1.onMessage(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139) > at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) > at org.jboss.as.test.integration.ejb.transaction.mdb.timeout.AnnotationTimeoutMDB$$$endpoint3.onMessage(Unknown Source) > at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:303) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) > at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) > 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.lang.ExceptionInInitializerError > at org.jboss.as.test.integration.transactions.TxTestUtil.(TxTestUtil.java:42) > at org.jboss.as.test.integration.ejb.transaction.mdb.timeout.AnnotationTimeoutMDB.onMessage(AnnotationTimeoutMDB.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:456) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:85) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:96) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254) > ... 58 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/mdb-timeout.jar )" of "ModuleClassLoader for Module "deployment.mdb-timeout.jar:main" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) > at java.lang.System.getProperty(System.java:717) > at java.lang.Integer.getInteger(Integer.java:1101) > at java.lang.Integer.getInteger(Integer.java:1057) > at org.jboss.as.test.shared.TimeoutUtil.(TimeoutUtil.java:39) > ... 83 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:02:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 02:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7738) XTS suspend tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFLY-7738: ----------------------------------- Assignee: Ivo Studensky > XTS suspend tests fail with security manager > -------------------------------------------- > > Key: WFLY-7738 > URL: https://issues.jboss.org/browse/WFLY-7738 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=AtomicTransactionSuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-5) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsat.AtomicTransactionExecutionService.init(AtomicTransactionExecutionService.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} > *org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BusinessActivitySuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-3) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsba.BusinessActivityExecutionService.init(BusinessActivityExecutionService.java:76) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:16:00 2017 From: issues at jboss.org (huanghwh (JIRA)) Date: Thu, 2 Mar 2017 02:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371296#comment-13371296 ] huanghwh commented on WFLY-7823: -------------------------------- [^wilfly.diff] [^AMQPQueueExample.java] > AMQP remote client failed to connect > ------------------------------------ > > Key: WFLY-7823 > URL: https://issues.jboss.org/browse/WFLY-7823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Environment: OS: Windows10 x64, > Java: 1.8.0_102 > WildFly 10.1 Final (the same also on 11 night build) - standalone > client: AmqpNetLite, v.1.2.2.0, Proton 0.14 > Reporter: Oleg Kozakevych > Assignee: Jeff Mesnil > Labels: amqp, artemis, wildfly > Attachments: server.log, server_debug.log, standalone.xml > > > AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly. > When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following: > {noformat} > [03:58:25.015] SEND AMQP 3 1 0 0 > [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1) > {noformat} > Server just does nothing, any traces, any response to client. > I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424) > {noformat} > The Artemis AMQP protocol implementation module (at /modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. ). > Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to /modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly. > {noformat} > Then I turned debug traces and see following exception: > {noformat} > 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException > 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996) > 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368) > 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205) > 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877) > 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226) > 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145) > 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160) > 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349) > 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257) > 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158) > 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81) > 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127) > 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619) > 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216) > 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527) > 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521) > 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351) > 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322) > 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299) > 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175) > 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) > 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244) > 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118) > 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745) > {noformat} > Configuration and server logs are attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:17:00 2017 From: issues at jboss.org (huanghwh (JIRA)) Date: Thu, 2 Mar 2017 02:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huanghwh updated WFLY-7823: --------------------------- Attachment: AMQPQueueExample.java > AMQP remote client failed to connect > ------------------------------------ > > Key: WFLY-7823 > URL: https://issues.jboss.org/browse/WFLY-7823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Environment: OS: Windows10 x64, > Java: 1.8.0_102 > WildFly 10.1 Final (the same also on 11 night build) - standalone > client: AmqpNetLite, v.1.2.2.0, Proton 0.14 > Reporter: Oleg Kozakevych > Assignee: Jeff Mesnil > Labels: amqp, artemis, wildfly > Attachments: AMQPQueueExample.java, server.log, server_debug.log, standalone.xml, wilfly.diff > > > AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly. > When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following: > {noformat} > [03:58:25.015] SEND AMQP 3 1 0 0 > [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1) > {noformat} > Server just does nothing, any traces, any response to client. > I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424) > {noformat} > The Artemis AMQP protocol implementation module (at /modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. ). > Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to /modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly. > {noformat} > Then I turned debug traces and see following exception: > {noformat} > 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException > 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996) > 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368) > 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205) > 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877) > 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226) > 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145) > 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160) > 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349) > 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257) > 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158) > 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81) > 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127) > 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619) > 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216) > 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527) > 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521) > 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351) > 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322) > 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299) > 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175) > 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) > 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244) > 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118) > 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745) > {noformat} > Configuration and server logs are attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:17:00 2017 From: issues at jboss.org (huanghwh (JIRA)) Date: Thu, 2 Mar 2017 02:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huanghwh updated WFLY-7823: --------------------------- Attachment: wilfly.diff > AMQP remote client failed to connect > ------------------------------------ > > Key: WFLY-7823 > URL: https://issues.jboss.org/browse/WFLY-7823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Environment: OS: Windows10 x64, > Java: 1.8.0_102 > WildFly 10.1 Final (the same also on 11 night build) - standalone > client: AmqpNetLite, v.1.2.2.0, Proton 0.14 > Reporter: Oleg Kozakevych > Assignee: Jeff Mesnil > Labels: amqp, artemis, wildfly > Attachments: AMQPQueueExample.java, server.log, server_debug.log, standalone.xml, wilfly.diff > > > AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly. > When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following: > {noformat} > [03:58:25.015] SEND AMQP 3 1 0 0 > [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1) > {noformat} > Server just does nothing, any traces, any response to client. > I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424) > {noformat} > The Artemis AMQP protocol implementation module (at /modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. ). > Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to /modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly. > {noformat} > Then I turned debug traces and see following exception: > {noformat} > 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException > 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996) > 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368) > 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205) > 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877) > 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226) > 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145) > 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160) > 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349) > 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257) > 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158) > 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81) > 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127) > 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619) > 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216) > 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527) > 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521) > 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351) > 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322) > 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299) > 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175) > 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) > 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244) > 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118) > 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745) > {noformat} > Configuration and server logs are attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:19:00 2017 From: issues at jboss.org (huanghwh (JIRA)) Date: Thu, 2 Mar 2017 02:19:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huanghwh updated WFLY-7823: --------------------------- Attachment: standalone-full.xml > AMQP remote client failed to connect > ------------------------------------ > > Key: WFLY-7823 > URL: https://issues.jboss.org/browse/WFLY-7823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Environment: OS: Windows10 x64, > Java: 1.8.0_102 > WildFly 10.1 Final (the same also on 11 night build) - standalone > client: AmqpNetLite, v.1.2.2.0, Proton 0.14 > Reporter: Oleg Kozakevych > Assignee: Jeff Mesnil > Labels: amqp, artemis, wildfly > Attachments: AMQPQueueExample.java, server.log, server_debug.log, standalone-full.xml, standalone.xml, wilfly.diff > > > AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly. > When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following: > {noformat} > [03:58:25.015] SEND AMQP 3 1 0 0 > [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1) > {noformat} > Server just does nothing, any traces, any response to client. > I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424) > {noformat} > The Artemis AMQP protocol implementation module (at /modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. ). > Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to /modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly. > {noformat} > Then I turned debug traces and see following exception: > {noformat} > 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException > 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996) > 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368) > 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205) > 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877) > 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226) > 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145) > 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160) > 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349) > 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257) > 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158) > 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81) > 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127) > 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619) > 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216) > 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527) > 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521) > 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351) > 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322) > 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299) > 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175) > 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) > 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244) > 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118) > 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745) > {noformat} > Configuration and server logs are attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:22:00 2017 From: issues at jboss.org (huanghwh (JIRA)) Date: Thu, 2 Mar 2017 02:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371296#comment-13371296 ] huanghwh edited comment on WFLY-7823 at 3/2/17 2:21 AM: -------------------------------------------------------- 1. I remove proton-jms at all, 2. wildfly.diff is what I change 3. AMQPQueueExample.java is test case. was (Author: huanghwh): [^wilfly.diff] [^AMQPQueueExample.java] > AMQP remote client failed to connect > ------------------------------------ > > Key: WFLY-7823 > URL: https://issues.jboss.org/browse/WFLY-7823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Environment: OS: Windows10 x64, > Java: 1.8.0_102 > WildFly 10.1 Final (the same also on 11 night build) - standalone > client: AmqpNetLite, v.1.2.2.0, Proton 0.14 > Reporter: Oleg Kozakevych > Assignee: Jeff Mesnil > Labels: amqp, artemis, wildfly > Attachments: AMQPQueueExample.java, server.log, server_debug.log, standalone-full.xml, standalone.xml, wilfly.diff > > > AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly. > When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following: > {noformat} > [03:58:25.015] SEND AMQP 3 1 0 0 > [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1) > {noformat} > Server just does nothing, any traces, any response to client. > I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424) > {noformat} > The Artemis AMQP protocol implementation module (at /modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. ). > Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to /modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly. > {noformat} > Then I turned debug traces and see following exception: > {noformat} > 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException > 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996) > 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368) > 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205) > 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877) > 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226) > 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145) > 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160) > 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349) > 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257) > 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158) > 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81) > 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127) > 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619) > 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216) > 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527) > 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521) > 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351) > 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322) > 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299) > 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175) > 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) > 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244) > 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118) > 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745) > {noformat} > Configuration and server logs are attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:23:00 2017 From: issues at jboss.org (huanghwh (JIRA)) Date: Thu, 2 Mar 2017 02:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371296#comment-13371296 ] huanghwh edited comment on WFLY-7823 at 3/2/17 2:22 AM: -------------------------------------------------------- 1. I remove proton-jms at all, I use proton-j-0.17.0 now. 2. wildfly.diff is what I change 3. AMQPQueueExample.java is test case. was (Author: huanghwh): 1. I remove proton-jms at all, 2. wildfly.diff is what I change 3. AMQPQueueExample.java is test case. > AMQP remote client failed to connect > ------------------------------------ > > Key: WFLY-7823 > URL: https://issues.jboss.org/browse/WFLY-7823 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Environment: OS: Windows10 x64, > Java: 1.8.0_102 > WildFly 10.1 Final (the same also on 11 night build) - standalone > client: AmqpNetLite, v.1.2.2.0, Proton 0.14 > Reporter: Oleg Kozakevych > Assignee: Jeff Mesnil > Labels: amqp, artemis, wildfly > Attachments: AMQPQueueExample.java, server.log, server_debug.log, standalone-full.xml, standalone.xml, wilfly.diff > > > AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly. > When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following: > {noformat} > [03:58:25.015] SEND AMQP 3 1 0 0 > [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1) > {noformat} > Server just does nothing, any traces, any response to client. > I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424) > {noformat} > The Artemis AMQP protocol implementation module (at /modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. ). > Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to /modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly. > {noformat} > Then I turned debug traces and see following exception: > {noformat} > 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException > 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996) > 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368) > 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205) > 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877) > 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226) > 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145) > 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160) > 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349) > 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257) > 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158) > 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81) > 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127) > 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619) > 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216) > 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527) > 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521) > 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351) > 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322) > 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299) > 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175) > 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) > 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244) > 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118) > 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745) > {noformat} > Configuration and server logs are attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 02:34:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 2 Mar 2017 02:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8271) Comparing incompatible types for equality: String.equals(org.jboss.dmr.ModelNode) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng moved JBEAP-9234 to WFLY-8271: ---------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8271 (was: JBEAP-9234) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Transactions (was: Transactions) Affects Version/s: (was: 7.1.0.DR12) > Comparing incompatible types for equality: String.equals(org.jboss.dmr.ModelNode) > --------------------------------------------------------------------------------- > > Key: WFLY-8271 > URL: https://issues.jboss.org/browse/WFLY-8271 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > I found case of comparison of incompatible types for equality: String.equals(org.jboss.dmr.ModelNode) > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystem14Parser.java#L221 > {code} > ... > final String value = reader.getAttributeValue(i); > ... > if (!value.equals(TransactionSubsystemRootResourceDefinition.OBJECT_STORE_PATH.getDefaultValue())) { > needsDefaultRelativeTo = false; > } > {code} > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AttributeDefinition.java#L349 > {code} > public ModelNode getDefaultValue() { > return defaultValue; > } > {code} > Please fix the code to compare the right types. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:00:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 2 Mar 2017 03:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1454) OSGi -fy the kie-dmn modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-1454: ----------------------------------- Assignee: Mario Fusco (was: Matteo Mortari) > OSGi -fy the kie-dmn modules > ---------------------------- > > Key: DROOLS-1454 > URL: https://issues.jboss.org/browse/DROOLS-1454 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:02:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 2 Mar 2017 03:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1454) OSGi -fy the kie-dmn modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371313#comment-13371313 ] Mario Fusco commented on DROOLS-1454: ------------------------------------- Implemented by: drools: https://github.com/droolsjbpm/drools/commit/779dcceb694599662e3dee5b6b092a0d8c7cde5c droolsjbpm-build-bootstrap: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/commit/911b89e6b6f550330f73451c126cb63f9b609ea3 droolsjbpm-integration: https://github.com/droolsjbpm/droolsjbpm-integration/commit/1e9d97b2a26a0e28309af768bebf1c68a043aed9 kie-dmn: https://github.com/droolsjbpm/kie-dmn/commit/afdc0fca516ae454f3bc7e8344537cb9d70e4191 > OSGi -fy the kie-dmn modules > ---------------------------- > > Key: DROOLS-1454 > URL: https://issues.jboss.org/browse/DROOLS-1454 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:10:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 03:10:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7593) JspTagTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371316#comment-13371316 ] Ivo Studensky commented on WFLY-7593: ------------------------------------- I couldn't reproduce this (upstream and 7.x, both passes with {{-Dsecurity.manager}}). The code around {{InjectionTargets}}, however, seems to be untouched and in sync with the stacktrace attached above, that's a little bit strange. > JspTagTestCase fails with security manager > ------------------------------------------ > > Key: WFLY-7593 > URL: https://issues.jboss.org/browse/WFLY-7593 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.jsp.JspTagTestCase#test* > {{./integration-tests.sh -DtestLogToFile=false -Dtest=JspTagTestCase -Dsecurity.manager}} > {code} > ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /ed26af0c-bc91-49ea-b6c3-196d33e8de5a/index2.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ )" of "org.apache.jasper.servlet.JasperLoader at a7277ba2") > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$425.00000000C40C2470.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(AccessController.java:650) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ )" of "org.apache.jasper.servlet.JasperLoader at a7277ba2") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.Class.getClassLoader(Class.java:442) > at org.jboss.as.weld.injection.InjectionTargets.createInjectionTarget(InjectionTargets.java:63) > at org.jboss.as.weld.deployment.WeldClassIntrospector.getInjectionTarget(WeldClassIntrospector.java:90) > at org.jboss.as.weld.deployment.WeldClassIntrospector.createInstance(WeldClassIntrospector.java:102) > at org.jboss.as.ee.component.ComponentRegistry.createInstance(ComponentRegistry.java:85) > at org.jboss.as.web.common.WebInjectionContainer.newInstance(WebInjectionContainer.java:77) > at org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager.newInstance(UndertowJSPInstanceManager.java:75) > at org.apache.jsp.index2_jsp._jspx_meth_my_005ftag_005f0(index2_jsp.java:128) > at org.apache.jsp.index2_jsp._jspService(index2_jsp.java:99) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) > ... 48 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:18:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 2 Mar 2017 03:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8268) Obtain password from external source (CMD, EXT) doesn't work on Windows. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFLY-8268: ------------------------------- Description: Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) {code} pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 Because when I add there back slashed to path then it works. was: Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 Because when I add there back slashed to path then it works. > Obtain password from external source (CMD, EXT) doesn't work on Windows. > ------------------------------------------------------------------------ > > Key: WFLY-8268 > URL: https://issues.jboss.org/browse/WFLY-8268 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Obtain password from external source (CMD, EXT) doesn't work on Windows. > Try to create new CS which obtains password from external source: > {code} > /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) > {code} > pass.bat file contains only this > {code} > echo %1 > {code} > Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: > Add new alias to CS -> JCEKS file is created > Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. > In my opinion there is problem with back slashes in script path. > https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 > Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:42:00 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Thu, 2 Mar 2017 03:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371332#comment-13371332 ] Prachi Yadav commented on HAWKULARQE-37: ---------------------------------------- Manual Test case execution complete. > Server Group Deployment > ----------------------- > > Key: HAWKULARQE-37 > URL: https://issues.jboss.org/browse/HAWKULARQE-37 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:45:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 03:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2161: --------------------------- Workaround Description: Set {{message_processing_policy="submit"}} in the transport > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:56:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 03:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-2161. ---------------------------- Resolution: Done > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 03:57:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 03:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371355#comment-13371355 ] Bela Ban commented on JGRP-2161: -------------------------------- Use JGroups-4.0.1-SNAPSHOT to test > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 04:02:01 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 04:02:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFCORE-1351: ------------------------------------- Assignee: Ivo Studensky (was: David Lloyd) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: Ivo Studensky > Priority: Critical > Fix For: 3.0.0.Beta7 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 04:49:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Thu, 2 Mar 2017 04:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8270) Fix and improve Undertow* tests in elytron module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek updated WFLY-8270: ------------------------------- Summary: Fix and improve Undertow* tests in elytron module (was: UndertowSslSecurityDomainTestCase - close client to avoid resource leaks) > Fix and improve Undertow* tests in elytron module > ------------------------------------------------- > > Key: WFLY-8270 > URL: https://issues.jboss.org/browse/WFLY-8270 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > > There are 4 tests in https://github.com/wildfly/wildfly/blob/master/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowSslSecurityDomainTestCase.java#L122 and each is creating client and making the call. > But the client is never closed. > I checked https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/Utils.java#L397 but it doesn't close the client either. > I think it makes sense to enhance those 4 tests with {{client.close();}} lines. > Changing Utils class can cause regressions when client is used for multiple calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 04:50:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Thu, 2 Mar 2017 04:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8270) Fix and improve Undertow* tests in elytron module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371413#comment-13371413 ] Ondrej Kotek commented on WFLY-8270: ------------------------------------ Also ignored tests are blocked no more. Documentation should be improved. > Fix and improve Undertow* tests in elytron module > ------------------------------------------------- > > Key: WFLY-8270 > URL: https://issues.jboss.org/browse/WFLY-8270 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > > There are 4 tests in https://github.com/wildfly/wildfly/blob/master/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowSslSecurityDomainTestCase.java#L122 and each is creating client and making the call. > But the client is never closed. > I checked https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/Utils.java#L397 but it doesn't close the client either. > I think it makes sense to enhance those 4 tests with {{client.close();}} lines. > Changing Utils class can cause regressions when client is used for multiple calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 04:59:00 2017 From: issues at jboss.org (Ramesh khot (JIRA)) Date: Thu, 2 Mar 2017 04:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8272) HttpServerExchange logout not happening after sessiontime out In-Reply-To: References: Message-ID: Ramesh khot created WFLY-8272: --------------------------------- Summary: HttpServerExchange logout not happening after sessiontime out Key: WFLY-8272 URL: https://issues.jboss.org/browse/WFLY-8272 Project: WildFly Issue Type: Bug Components: JSF, Security Affects Versions: 10.1.0.Final Reporter: Ramesh khot Assignee: Farah Juma I have an application deployed on wildfly-10.1.0.Final, using picketbox form based authentication integrated with SSO, we are using Jsf framework After ExternalContext.invalidateSession(); call UsernamePasswordLoginModule.logout() method is not triggered, which is used to happen in Jboss EAP 6.*, now I am calling request.logout() to flush the session data, which works for me After session time out invalidateSession is called but its not flushing session data, log says exchange null io.undertow.session trace log: *When request.logout():* 00:19:14,602 DEBUG [io.undertow.session] (default task-45) Invalidating session WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E for exchange HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logging out user guest1 for HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logged out HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} *After session time out:* Invalidating session H3Gy64JardrjwVMSxvKswFibxq136utoEnjZLdeG for exchange null -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 05:08:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 2 Mar 2017 05:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-50) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-50: ---------------------------------------- Summary: Manual Testcases - Create and Run Key: HAWKULARQE-50 URL: https://issues.jboss.org/browse/HAWKULARQE-50 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Prachi Yadav -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 05:08:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 2 Mar 2017 05:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-51) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-51: ---------------------------------------- Summary: Manual Testcases - Create and Run Key: HAWKULARQE-51 URL: https://issues.jboss.org/browse/HAWKULARQE-51 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Prachi Yadav -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 05:17:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 05:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371438#comment-13371438 ] Ivo Studensky commented on WFCORE-1351: --------------------------------------- This issue needs another component upgrade, see WFNC-23. > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: Ivo Studensky > Priority: Critical > Fix For: 3.0.0.Beta7 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 05:22:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 05:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8273) Upgrade to WildFly Naming Client 1.0.0.Beta12 In-Reply-To: References: Message-ID: Ivo Studensky created WFLY-8273: ----------------------------------- Summary: Upgrade to WildFly Naming Client 1.0.0.Beta12 Key: WFLY-8273 URL: https://issues.jboss.org/browse/WFLY-8273 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Ivo Studensky Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 05:26:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 05:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8273) Upgrade to WildFly Naming Client 1.0.0.Beta12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reassigned WFLY-8273: ----------------------------------- Assignee: David Lloyd (was: Farah Juma) > Upgrade to WildFly Naming Client 1.0.0.Beta12 > --------------------------------------------- > > Key: WFLY-8273 > URL: https://issues.jboss.org/browse/WFLY-8273 > Project: WildFly > Issue Type: Component Upgrade > Components: Naming > Reporter: Ivo Studensky > Assignee: David Lloyd > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 05:31:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 05:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8274) Upgrade to WildFly Naming Client 1.0.0.Beta12 In-Reply-To: References: Message-ID: Ivo Studensky created WFLY-8274: ----------------------------------- Summary: Upgrade to WildFly Naming Client 1.0.0.Beta12 Key: WFLY-8274 URL: https://issues.jboss.org/browse/WFLY-8274 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Ivo Studensky Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 06:07:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Mar 2017 06:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA In-Reply-To: References: Message-ID: Ondra Chaloupka created WFLY-8275: ------------------------------------- Summary: 2PC Inflow transactions don't work for JTA Key: WFLY-8275 URL: https://issues.jboss.org/browse/WFLY-8275 Project: WildFly Issue Type: Bug Components: Transactions, JCA Reporter: Ondra Chaloupka Assignee: Tom Jenkinson Priority: Blocker Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction. In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants. It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call. {code} 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98) at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445) at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Full log attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 06:07:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Mar 2017 06:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned WFLY-8275: ------------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > 2PC Inflow transactions don't work for JTA > ------------------------------------------ > > Key: WFLY-8275 > URL: https://issues.jboss.org/browse/WFLY-8275 > Project: WildFly > Issue Type: Bug > Components: JCA, Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction. > In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants. > It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call. > {code} > 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98) > at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) > at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445) > at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Full log attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 06:10:01 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 2 Mar 2017 06:10:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371479#comment-13371479 ] Ivo Studensky commented on WFCORE-1351: --------------------------------------- Except of WFNC-23 posted above, it works now. The testcase, however, contains permissions which are not needed in order to pass successfully on Security Manager. So I've filed PR to remove them. > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: Ivo Studensky > Priority: Critical > Fix For: 3.0.0.Beta7 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 06:13:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Mar 2017 06:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371481#comment-13371481 ] Ondra Chaloupka commented on WFLY-8275: --------------------------------------- This issue being fixed needs fix in wildfly transactional client which is part of version 1.0.0.Beta18 then wiring in connector subsystem needs to be done and fix in Narayana to wiring from JCA works too. > 2PC Inflow transactions don't work for JTA > ------------------------------------------ > > Key: WFLY-8275 > URL: https://issues.jboss.org/browse/WFLY-8275 > Project: WildFly > Issue Type: Bug > Components: JCA, Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction. > In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants. > It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call. > {code} > 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98) > at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) > at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445) > at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Full log attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 06:13:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Mar 2017 06:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371481#comment-13371481 ] Ondra Chaloupka edited comment on WFLY-8275 at 3/2/17 6:12 AM: --------------------------------------------------------------- This issue being fixed needs fix in wildfly transactional client which is part of version 1.0.0.Beta18 (see https://github.com/wildfly/wildfly-transaction-client/pull/14) then wiring in connector subsystem needs to be done and fix in Narayana to wiring from JCA works too. was (Author: ochaloup): This issue being fixed needs fix in wildfly transactional client which is part of version 1.0.0.Beta18 then wiring in connector subsystem needs to be done and fix in Narayana to wiring from JCA works too. > 2PC Inflow transactions don't work for JTA > ------------------------------------------ > > Key: WFLY-8275 > URL: https://issues.jboss.org/browse/WFLY-8275 > Project: WildFly > Issue Type: Bug > Components: JCA, Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction. > In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants. > It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call. > {code} > 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98) > at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) > at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445) > at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Full log attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 06:32:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 06:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-984) Bring dependency versions up to date with WildFly Core and WildFly In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-984: ------------------------------------ Summary: Bring dependency versions up to date with WildFly Core and WildFly Key: ELY-984 URL: https://issues.jboss.org/browse/ELY-984 Project: WildFly Elytron Issue Type: Enhancement Components: Build Reporter: Darran Lofthouse Fix For: 1.1.0.Beta28 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 07:46:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 2 Mar 2017 07:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-1563: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1417679 Bugzilla Update: Perform > Failed CLI batch command with "deploy --force" for replace deployment > --------------------------------------------------------------------- > > Key: WFCORE-1563 > URL: https://issues.jboss.org/browse/WFCORE-1563 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.1.0.Final, 3.0.0.Alpha1 > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: cli, jboss > Fix For: 3.0.0.Alpha2 > > Attachments: jboss-ejb-in-ear.ear > > > Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part." > {code:title=Command} > jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli" > {code} > {code:title=deploy.cli} > batch > deploy --force ./jboss-ejb-in-ear.ear > run-batch > {code} > {panel:title=Full Error message} > Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part. > or > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part. > {panel} > {panel:title=Expected message} > The batch executed successfully > {panel} > However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error. > There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below. > Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle() > ------------------------------------------------------------------------------------------- > * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd() > {code} > { > "operation" => "add", > "address" => {"deployment" => "jboss-ejb-in-ear.ear"}, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- > * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace() > {code} > { > "operation" => "full-replace-deployment", > "name" => "jboss-ejb-in-ear.ear", > "enabled" => true, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- > * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace() > {code} > { > "operation" => "full-replace-deployment", > "name" => "jboss-ejb-in-ear.ear", > "address" => [], > "enabled" => true, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 08:16:00 2017 From: issues at jboss.org (Radovan Stancel (JIRA)) Date: Thu, 2 Mar 2017 08:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts. In-Reply-To: References: Message-ID: Radovan Stancel created WFCORE-2348: --------------------------------------- Summary: Error while starting WildFly as service in domain mode using init scripts. Key: WFCORE-2348 URL: https://issues.jboss.org/browse/WFCORE-2348 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 3.0.0.Alpha18 Environment: Fedora, RHEL Reporter: Radovan Stancel Assignee: Radovan Stancel Priority: Minor When starting WildFly as a service in domain mode using init scripts there appears in console.log error: /usr/bin/dirname: unrecognized option '--domain-config=domain.xml' Try '/usr/bin/dirname --help' for more information. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 08:21:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Thu, 2 Mar 2017 08:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1460) DMN extension for kie-server In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1460: -------------------------------------- Summary: DMN extension for kie-server Key: DROOLS-1460 URL: https://issues.jboss.org/browse/DROOLS-1460 Project: Drools Issue Type: Feature Request Components: dmn engine, kie server Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 08:26:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 2 Mar 2017 08:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371561#comment-13371561 ] Tomas Hofman commented on WFLY-8238: ------------------------------------ Thanks [~brian.stansberry], that's what I suspected. I'm working on removing {{AlternativeAttributeCheckHandler}} and finding a sensible setting for affected attributes. These are the affected attributes: Bridge: discovery-group, static-connectors ClusterConnection: discovery-group, allow-direct-connection-only, connector-refs BroadcastGroup, DiscoveryGroup: socket-binding, jgroups-channel LiveOnly, ReplicationSlave, SharedStoreSlave: scale-down-connectors, scale-down-discovery-group ConnectionFactory, PooledConnectionFactory: discovery-group, connectors All of those attributes are currently marked as optional, however in same cases the attributes are required during resource creation by a custom validation. In those cases I intend to change them to required. > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 08:32:00 2017 From: issues at jboss.org (Radovan Stancel (JIRA)) Date: Thu, 2 Mar 2017 08:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radovan Stancel updated WFCORE-2348: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2221 Affects Version/s: 3.0.0.Beta7 (was: 3.0.0.Alpha18) > Error while starting WildFly as service in domain mode using init scripts. > -------------------------------------------------------------------------- > > Key: WFCORE-2348 > URL: https://issues.jboss.org/browse/WFCORE-2348 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta7 > Environment: Fedora, RHEL > Reporter: Radovan Stancel > Assignee: Radovan Stancel > Priority: Minor > Labels: downstream_dependency > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When starting WildFly as a service in domain mode using init scripts there appears in console.log error: > /usr/bin/dirname: unrecognized option '--domain-config=domain.xml' > Try '/usr/bin/dirname --help' for more information. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 08:37:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 2 Mar 2017 08:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371570#comment-13371570 ] Tomas Hofman commented on WFLY-8238: ------------------------------------ The final settings is: Bridge: discovery-group, static-connectors - *required* ClusterConnection: discovery-group, allow-direct-connection-only, connector-refs - *optional* BroadcastGroup, DiscoveryGroup: socket-binding, jgroups-channel - *optional* LiveOnly, ReplicationSlave, SharedStoreSlave: scale-down-connectors, scale-down-discovery-group - *optional* ConnectionFactory, PooledConnectionFactory: discovery-group, connectors - *required* > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:22:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 2 Mar 2017 09:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371601#comment-13371601 ] Brian Stansberry commented on WFLY-8238: ---------------------------------------- Prior to some improvements in WildFly Core late last year attributes with alternatives were marked as optional even though one or the other of the alternatives had to be set. This wasn't a correct description of the situation, but was rather a workaround for a weakness in core. See WFCORE-1556 for details. I just skimmed your comments today and haven't looked at the attributes you mention but I wouldn't be surprised if they were the way they were because of needing to work around that weakness. If that's what it was, removing the workaround and correcting the descriptions is good. > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:26:00 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Thu, 2 Mar 2017 09:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated on failed operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371603#comment-13371603 ] Prachi Yadav commented on HAWKULARQE-44: ---------------------------------------- executed Test cases https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-9923 https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-9559 https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-9328 > Verify events generated on failed operations > -------------------------------------------- > > Key: HAWKULARQE-44 > URL: https://issues.jboss.org/browse/HAWKULARQE-44 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Prachi Yadav > > Few test cases(Related to events genration due to failed operation) were blocked due to below bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1396238 > Tasks: > 1) Re-verify blocked test cases and mark the status in polarion > 2) Execute test cases related to below scenarios if test cases exists > 3) Add test cases if does not exist and execute test cases > 4) Log bugs if test cases fail > Scenarios: > EAP application Deployment failure > EAP application Undeployment failure > Datasource creation Failure > Datasource deletion Failure -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:27:00 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Thu, 2 Mar 2017 09:27:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated on failed operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Yadav resolved HAWKULARQE-44. ------------------------------------ Resolution: Done > Verify events generated on failed operations > -------------------------------------------- > > Key: HAWKULARQE-44 > URL: https://issues.jboss.org/browse/HAWKULARQE-44 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Prachi Yadav > > Few test cases(Related to events genration due to failed operation) were blocked due to below bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1396238 > Tasks: > 1) Re-verify blocked test cases and mark the status in polarion > 2) Execute test cases related to below scenarios if test cases exists > 3) Add test cases if does not exist and execute test cases > 4) Log bugs if test cases fail > Scenarios: > EAP application Deployment failure > EAP application Undeployment failure > Datasource creation Failure > Datasource deletion Failure -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:41:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 2 Mar 2017 09:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-45) Setup Jenkins Slave server on openstack to run cf-ui smoke test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371611#comment-13371611 ] Sunil kondkar commented on HAWKULARQE-45: ----------------------------------------- Created vm on openstack: 10.8.184.19 Installed Python , Chrome/FF, Headless Selenium, xvfb, tigervnc created hudson user, setup as Jenkins slave completed. Investigating some errors while executing setup.sh http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/miq-ms-cfui-nightly/162/console > Setup Jenkins Slave server on openstack to run cf-ui smoke test suite > --------------------------------------------------------------------- > > Key: HAWKULARQE-45 > URL: https://issues.jboss.org/browse/HAWKULARQE-45 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > At present Jenkins slave is on BC and sometimes smoke test suites fai due to timeout issue. This task is to setup Jenkins slave on openstack instance. > Install: > Python > Chrome/FF > Headless Selenium > xvfb > connect via vnc -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:45:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Thu, 2 Mar 2017 09:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8237) Upgrade to xalan 2.7.1.jbossorg-4 and include fix for cve-2014-0107 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Marlow updated WFLY-8237: ------------------------------- Summary: Upgrade to xalan 2.7.1.jbossorg-4 and include fix for cve-2014-0107 (was: Upgrade to xalan 2.7.1.jbossorg-3 and include fix for cve-2014-0107) > Upgrade to xalan 2.7.1.jbossorg-4 and include fix for cve-2014-0107 > ------------------------------------------------------------------- > > Key: WFLY-8237 > URL: https://issues.jboss.org/browse/WFLY-8237 > Project: WildFly > Issue Type: Task > Components: XML Frameworks > Reporter: Scott Marlow > Assignee: Scott Marlow > > EAP is still using 2.7.1 with our patches on top of it. > It would be wise to upgrade to 2.7.2 and add any missing patches we did to 2.7.1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:48:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Thu, 2 Mar 2017 09:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5128) TimeoutException: Could not acquire lock: Waiting to complete tx In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-5128: --------------------------------- Labels: (was: clustering_revalidate) > TimeoutException: Could not acquire lock: Waiting to complete tx > ---------------------------------------------------------------- > > Key: WFLY-5128 > URL: https://issues.jboss.org/browse/WFLY-5128 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1, 10.0.0.CR2 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Fix For: 10.0.0.CR3 > > > Seen in these scenarios: > ejbservlet - shutdown/undeploy > http session - shutdown/undeploy > Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application. > Approx. 30 seconds after failing one node, one or more nodes intermittently log this error: > {code} > [JBossINF] 16:32:07,395 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (transport-thread--p7-t21) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on la5hJBZTPNMkBJCXILk9IzqA36rlEU-rSIUIwB-x on behalf of transaction GlobalTransaction::3179:local. Waiting to complete tx: RemoteTransaction{modifications=[], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=[la5hJBZTPNMkBJCXILk9IzqA36rlEU-rSIUIwB-x, la5hJBZTPNMkBJCXILk9IzqA36rlEU-rSIUIwB-x], lookedUpEntriesTopology=2147483647, isMarkedForRollback=false, tx=GlobalTransaction::31071:remote, state=null}. > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.newTimeoutException(AbstractTxLockingInterceptor.java:217) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.waitForTransactionsToComplete(AbstractTxLockingInterceptor.java:209) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:173) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:68) > [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:287) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:259) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:360) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:345) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103) > [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430) > [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427) > [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.schedule(InfinispanSessionManager.java:384) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.dataRehashed(InfinispanSessionManager.java:369) > [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497) > [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286) > [JBossINF] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) > [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1170) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1135) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyDataRehashed(CacheNotifierImpl.java:576) > [JBossINF] at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:385) > [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:200) > [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:47) > [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:115) > [JBossINF] at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:282) > [JBossINF] at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:217) > [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [JBossINF] at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173) > [JBossINF] at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > This error may be the root cause of https://issues.jboss.org/browse/JBEAP-505 (server ends up with Operation ("deploy") failed when restarted after failover). > The following error (and matching warning), occurring just before the above mentioned TimeoutException, is most likely also related: > {code} > [JBossINF] 16:31:56,503 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p3-t41) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key perf21 and requestor GlobalTransaction::78599:remote. Lock is held by GlobalTransaction::78433:remote, while request came from perf21 > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198) > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:185) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:118) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:200) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:141) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:199) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:196) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:99) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:76) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:129) > [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:85) > [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] 16:31:56,504 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderPerCacheInboundInvocationHandler] (remote-thread--p3-t41) ISPN000071: Caught exception when handling command LockControlCommand{cache=dist, keys=[perf21], flags=[IGNORE_RETURN_VALUES], unlock=false, gtx=GlobalTransaction::78599:remote}: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key perf21 and requestor GlobalTransaction::78599:remote. Lock is held by GlobalTransaction::78433:remote, while request came from perf21 > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198) > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:185) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:118) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:200) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:141) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:199) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:196) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:99) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:76) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:129) > [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:85) > [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > Server log: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-session-shutdown-dist-sync/4/console-perf19/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:50:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 09:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2349: ---------------------------------------- Summary: Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. Key: WFCORE-2349 URL: https://issues.jboss.org/browse/WFCORE-2349 Project: WildFly Core Issue Type: Enhancement Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta7 Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:52:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 09:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2350) In legacy security realms grant RemoteEJBPermission and RemoteTransactionPermission by default. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2350: ---------------------------------------- Summary: In legacy security realms grant RemoteEJBPermission and RemoteTransactionPermission by default. Key: WFCORE-2350 URL: https://issues.jboss.org/browse/WFCORE-2350 Project: WildFly Core Issue Type: Enhancement Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta7 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:57:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Thu, 2 Mar 2017 09:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8272) HttpServerExchange logout not happening after sessiontime out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma updated WFLY-8272: ----------------------------- Component/s: (was: JSF) > HttpServerExchange logout not happening after sessiontime out > ------------------------------------------------------------- > > Key: WFLY-8272 > URL: https://issues.jboss.org/browse/WFLY-8272 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Reporter: Ramesh khot > Assignee: Farah Juma > > I have an application deployed on wildfly-10.1.0.Final, using picketbox form based authentication integrated with SSO, we are using Jsf framework > After ExternalContext.invalidateSession(); call UsernamePasswordLoginModule.logout() method is not triggered, which is used to happen in Jboss EAP 6.*, now I am calling request.logout() to flush the session data, which works for me > After session time out invalidateSession is called but its not flushing session data, log says exchange null > io.undertow.session trace log: > *When request.logout():* > 00:19:14,602 DEBUG [io.undertow.session] (default task-45) Invalidating session WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E for exchange HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logging out user guest1 for HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logged out HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > *After session time out:* > Invalidating session H3Gy64JardrjwVMSxvKswFibxq136utoEnjZLdeG for exchange null -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:58:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Thu, 2 Mar 2017 09:58:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8272) HttpServerExchange logout not happening after sessiontime out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma reassigned WFLY-8272: -------------------------------- Assignee: (was: Darran Lofthouse) > HttpServerExchange logout not happening after sessiontime out > ------------------------------------------------------------- > > Key: WFLY-8272 > URL: https://issues.jboss.org/browse/WFLY-8272 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Reporter: Ramesh khot > > I have an application deployed on wildfly-10.1.0.Final, using picketbox form based authentication integrated with SSO, we are using Jsf framework > After ExternalContext.invalidateSession(); call UsernamePasswordLoginModule.logout() method is not triggered, which is used to happen in Jboss EAP 6.*, now I am calling request.logout() to flush the session data, which works for me > After session time out invalidateSession is called but its not flushing session data, log says exchange null > io.undertow.session trace log: > *When request.logout():* > 00:19:14,602 DEBUG [io.undertow.session] (default task-45) Invalidating session WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E for exchange HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logging out user guest1 for HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logged out HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > *After session time out:* > Invalidating session H3Gy64JardrjwVMSxvKswFibxq136utoEnjZLdeG for exchange null -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 09:58:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Thu, 2 Mar 2017 09:58:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8272) HttpServerExchange logout not happening after sessiontime out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma reassigned WFLY-8272: -------------------------------- Assignee: Darran Lofthouse (was: Farah Juma) > HttpServerExchange logout not happening after sessiontime out > ------------------------------------------------------------- > > Key: WFLY-8272 > URL: https://issues.jboss.org/browse/WFLY-8272 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Reporter: Ramesh khot > Assignee: Darran Lofthouse > > I have an application deployed on wildfly-10.1.0.Final, using picketbox form based authentication integrated with SSO, we are using Jsf framework > After ExternalContext.invalidateSession(); call UsernamePasswordLoginModule.logout() method is not triggered, which is used to happen in Jboss EAP 6.*, now I am calling request.logout() to flush the session data, which works for me > After session time out invalidateSession is called but its not flushing session data, log says exchange null > io.undertow.session trace log: > *When request.logout():* > 00:19:14,602 DEBUG [io.undertow.session] (default task-45) Invalidating session WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E for exchange HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logging out user guest1 for HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > 00:19:18,864 DEBUG [io.undertow.request.security] (default task-45) Logged out HttpServerExchange{ POST /plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,en-GB;q=0.2], Accept-Encoding=[gzip, deflate], DNT=[1], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0; Firefox 45.7.0 - 11712-1502320053-1.34], Connection=[keep-alive], Cookie=[j_username=guest1; j_password=passguest1; JSESSIONID=WUZTg0SSQXsbqgByND0Mpz1SMtcLExt7vGgrVr-E.bmh1058602; JSESSIONIDSSO=PSz_b3ZYOtUYMPDC5_rdS-volKYXMH2j0pY-NLfe], Content-Type=[application/x-www-form-urlencoded], Content-Length=[116], Referer=[http://localhost:8090/plcdng_slim_dev/BootstrapUI/pages/protected/user/bootstrap.xhtml], Host=[localhost:8090]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/10], Pragma=[no-cache]}} > *After session time out:* > Invalidating session H3Gy64JardrjwVMSxvKswFibxq136utoEnjZLdeG for exchange null -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:10:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 2 Mar 2017 10:10:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8276) Upgrade JBeret from 1.2.2.Final to 1.2.3.Final In-Reply-To: References: Message-ID: James Perkins created WFLY-8276: ----------------------------------- Summary: Upgrade JBeret from 1.2.2.Final to 1.2.3.Final Key: WFLY-8276 URL: https://issues.jboss.org/browse/WFLY-8276 Project: WildFly Issue Type: Component Upgrade Components: Batch Reporter: James Perkins Assignee: James Perkins Once JBeret 1.2.3.Final is released and upgrade of the component should be done. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:11:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 2 Mar 2017 10:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8277) Upgrade JBeret from 1.2.2.Final to 1.2.3.Final In-Reply-To: References: Message-ID: James Perkins created WFLY-8277: ----------------------------------- Summary: Upgrade JBeret from 1.2.2.Final to 1.2.3.Final Key: WFLY-8277 URL: https://issues.jboss.org/browse/WFLY-8277 Project: WildFly Issue Type: Component Upgrade Components: Batch Reporter: James Perkins Assignee: James Perkins Once JBeret 1.2.3.Final is released and upgrade of the component should be done. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:16:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Thu, 2 Mar 2017 10:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-15) [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371638#comment-13371638 ] Matt Mahoney commented on HAWKULARQE-15: ---------------------------------------- Waiting on [JMAN4-159|https://issues.jboss.org/browse/JMAN4-159] and[ JMAN4-160|https://issues.jboss.org/browse/JMAN4-160]. > [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager > -------------------------------------------------------------------------- > > Key: HAWKULARQE-15 > URL: https://issues.jboss.org/browse/HAWKULARQE-15 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > Labels: mm-integration-hawkular-qe > > See [JMAN4-163|https://issues.jboss.org/browse/JMAN4-163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:16:00 2017 From: issues at jboss.org (Jan Martiska (JIRA)) Date: Thu, 2 Mar 2017 10:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8278) Create smoke test for Elytron integration with Batch subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Martiska moved JBEAP-9253 to WFLY-8278: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8278 (was: JBEAP-9253) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Batch Security (was: Batch) (was: Security) > Create smoke test for Elytron integration with Batch subsystem > -------------------------------------------------------------- > > Key: WFLY-8278 > URL: https://issues.jboss.org/browse/WFLY-8278 > Project: WildFly > Issue Type: Task > Components: Batch, Security > Reporter: Jan Martiska > Assignee: Jan Martiska > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:16:01 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Thu, 2 Mar 2017 10:16:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-15) [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371638#comment-13371638 ] Matt Mahoney edited comment on HAWKULARQE-15 at 3/2/17 10:15 AM: ----------------------------------------------------------------- Waiting on [JMAN4-159|https://issues.jboss.org/browse/JMAN4-159] and [ JMAN4-160|https://issues.jboss.org/browse/JMAN4-160]. was (Author: mmahoney): Waiting on [JMAN4-159|https://issues.jboss.org/browse/JMAN4-159] and[ JMAN4-160|https://issues.jboss.org/browse/JMAN4-160]. > [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager > -------------------------------------------------------------------------- > > Key: HAWKULARQE-15 > URL: https://issues.jboss.org/browse/HAWKULARQE-15 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > Labels: mm-integration-hawkular-qe > > See [JMAN4-163|https://issues.jboss.org/browse/JMAN4-163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:17:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Thu, 2 Mar 2017 10:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-15) [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371638#comment-13371638 ] Matt Mahoney edited comment on HAWKULARQE-15 at 3/2/17 10:16 AM: ----------------------------------------------------------------- Waiting on [JMAN4-159|https://issues.jboss.org/browse/JMAN4-159] and [JMAN4-160|https://issues.jboss.org/browse/JMAN4-160]. was (Author: mmahoney): Waiting on [JMAN4-159|https://issues.jboss.org/browse/JMAN4-159] and [ JMAN4-160|https://issues.jboss.org/browse/JMAN4-160]. > [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager > -------------------------------------------------------------------------- > > Key: HAWKULARQE-15 > URL: https://issues.jboss.org/browse/HAWKULARQE-15 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > Labels: mm-integration-hawkular-qe > > See [JMAN4-163|https://issues.jboss.org/browse/JMAN4-163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:23:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 2 Mar 2017 10:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8279) CS tool generated different MASKED password then vault.sh In-Reply-To: References: Message-ID: Hynek ?v?bek created WFLY-8279: ---------------------------------- Summary: CS tool generated different MASKED password then vault.sh Key: WFLY-8279 URL: https://issues.jboss.org/browse/WFLY-8279 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse CS tool generated different MASKED password then vault.sh When I run oldf vault.sh {code} ./vault.sh --keystore key.store --keystore-password secret_password --alias Vault --vault-block vaultBlock --attribute passDB --sec-attr secretvalue --enc-dir ./vault --iteration 230 --salt 12345678 -t {code} I can see this *MASK-1GhfMaq4jSY0.kFFU3QG4T* Whole output: {code:collapse=true} {code} In the other hand when I run new CS tool with params: {code} java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret secretpassword --location="test.store1" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password secret_password --summary --salt 12345678 --iteration 230 --create {code} I get *MASK-KAwLfD1BN8WFhZptWsa17G* Whole output: {code:collapse=true} Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-KAwLfD1BN8WFhZptWsa17G==;12345678;230"}) {code} *I set these values for both:* password to mask *secret_password* iteration *12345678* salt *230* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:34:01 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 2 Mar 2017 10:34:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-84) Configurable default Locale for Logger#getMessageLogger() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated JBLOGGING-84: ----------------------------------- Fix Version/s: 3.3.1.Final > Configurable default Locale for Logger#getMessageLogger() > --------------------------------------------------------- > > Key: JBLOGGING-84 > URL: https://issues.jboss.org/browse/JBLOGGING-84 > Project: JBoss Logging > Issue Type: Feature Request > Reporter: Michael Locher > Assignee: James Perkins > Fix For: 3.3.1.Final > > > Please make the Locale for org.jboss.logging.Logger#getMessageLogger configurable (e.g. via a system property). > Use Case: > Having different locales for 'application code' which is deployed in JBAPP (specified as JVM default at startup and available via Locale.getDefault()) and the locale for logging of JBAPP. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 10:42:02 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 2 Mar 2017 10:42:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8280) JobControlTestCase fails intermittently In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved JBEAP-9255 to WFLY-8280: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8280 (was: JBEAP-9255) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.1.0.DR10) > JobControlTestCase fails intermittently > --------------------------------------- > > Key: WFLY-8280 > URL: https://issues.jboss.org/browse/WFLY-8280 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > > *Description of problem:* > JobControlTestCase fails intermittently > *How reproducible:* > 5% > *Actual results:* > StackTrace: > {noformat} > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.integration.batch.deployment.JobControlTestCase.testRestart(JobControlTestCase.java:198) > {noformat} > Standard output: > {noformat} > &#27;[31m16:18:12,813 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-5-thread-1) Failed: org.jboss.as.test.integration.batch.deployment.JobControlTestCase.testRestart: java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.integration.batch.deployment.JobControlTestCase.testRestart(JobControlTestCase.java:198) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > &#27;[0m16:18:12,940 SEVERE [org.jboss.arquillian.protocol.jmx.JMXMethodExecutor] (main) Failed: org.jboss.as.test.integration.batch.deployment.JobControlTestCase.testRestart: java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.integration.batch.deployment.JobControlTestCase.testRestart(JobControlTestCase.java:198) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > {noformat} > *Expected results:* > No error -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 11:37:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 2 Mar 2017 11:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-957) Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371694#comment-13371694 ] Martin Choma commented on ELY-957: ---------------------------------- Ok, I think I got it now, thanxs. > Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized > ---------------------------------------------------------------------------- > > Key: ELY-957 > URL: https://issues.jboss.org/browse/ELY-957 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Paul Ferraro > Priority: Minor > > Coverity static-analysis scan found getter is not synchronized, while setter is. > {code} > public SecurityIdentity getIdentity() { > return this.entry.getCachedIdentity().getSecurityIdentity(); > } > {code} > Current implementation is correct because in DefaultSingleSignOnEntry (currently only avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile. > However other implementations can be wrongly implemented. Once getIdentity() would be marked with synchronize modifier, such problem shouldn't occure. > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490896&defectInstanceId=2123245&mergedDefectId=1396940 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 11:38:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 2 Mar 2017 11:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7971) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFLY-7971: ------------------------------- Component/s: Domain Management (was: Security) > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7971 > URL: https://issues.jboss.org/browse/WFLY-7971 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 11:38:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 2 Mar 2017 11:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7971) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek reassigned WFLY-7971: ---------------------------------- Assignee: Brian Stansberry (was: Darran Lofthouse) > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7971 > URL: https://issues.jboss.org/browse/WFLY-7971 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 11:40:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 2 Mar 2017 11:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek moved WFLY-7971 to WFCORE-2351: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2351 (was: WFLY-7971) Component/s: Domain Management (was: Domain Management) > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2351 > URL: https://issues.jboss.org/browse/WFCORE-2351 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 11:56:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 2 Mar 2017 11:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8281) Create test for SPNEGO using Elytron In-Reply-To: References: Message-ID: Martin Choma created WFLY-8281: ---------------------------------- Summary: Create test for SPNEGO using Elytron Key: WFLY-8281 URL: https://issues.jboss.org/browse/WFLY-8281 Project: WildFly Issue Type: Task Components: Security, Test Suite Reporter: Martin Choma Assignee: Martin Choma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:10:01 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 12:10:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371714#comment-13371714 ] Bela Ban commented on JGRP-2159: -------------------------------- I also revamped the view ack collection mechanism a bit: {{GMS.castViewChange()}} now broadcasts the view and sends JOIN responses to joining members if needed, then blocks for all acks from existing members (minus self) and joining members. For merge views, only acks from this side of the partition are waited for. > Delta view cannot be installed > ------------------------------ > > Key: JGRP-2159 > URL: https://issues.jboss.org/browse/JGRP-2159 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1, 4.0.1 > > Attachments: discarded_delta_view.log > > > A DeltaView cannot be installed because the ref view-id is not the current view-id. > Looking at the view sequence for members J, K and L: > {noformat} > 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J] > 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K] > 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K] > 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K] > 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L] > 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L] > {noformat} > K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1. > The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1. > We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead. > See the attached log. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:10:02 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 12:10:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-2159. ---------------------------- Resolution: Done > Delta view cannot be installed > ------------------------------ > > Key: JGRP-2159 > URL: https://issues.jboss.org/browse/JGRP-2159 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1, 4.0.1 > > Attachments: discarded_delta_view.log > > > A DeltaView cannot be installed because the ref view-id is not the current view-id. > Looking at the view sequence for members J, K and L: > {noformat} > 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J] > 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K] > 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K] > 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K] > 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L] > 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L] > {noformat} > K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1. > The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1. > We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead. > See the attached log. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:25:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 12:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2352) Migrate the WildFly Elytron subsystem to WildFly Core In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2352: ---------------------------------------- Summary: Migrate the WildFly Elytron subsystem to WildFly Core Key: WFCORE-2352 URL: https://issues.jboss.org/browse/WFCORE-2352 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta7 This task is to move the subsystem to WildFly Core. This task is not to add the subsystem to any additional feature packs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:41:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 12:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2161: --------------------------- Fix Version/s: (was: 4.1) > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:41:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 12:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2159: --------------------------- Fix Version/s: (was: 4.1) > Delta view cannot be installed > ------------------------------ > > Key: JGRP-2159 > URL: https://issues.jboss.org/browse/JGRP-2159 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.1 > > Attachments: discarded_delta_view.log > > > A DeltaView cannot be installed because the ref view-id is not the current view-id. > Looking at the view sequence for members J, K and L: > {noformat} > 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J] > 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K] > 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K] > 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K] > 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L] > 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L] > {noformat} > K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1. > The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1. > We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead. > See the attached log. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:42:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 2 Mar 2017 12:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2160) Custom code to pick bind address In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2160: --------------------------- Fix Version/s: (was: 4.1) > Custom code to pick bind address > -------------------------------- > > Key: JGRP-2160 > URL: https://issues.jboss.org/browse/JGRP-2160 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.1 > > > Example: > {{bind_addr="custom:com.acme.BindAddressPicker"}}. > The fully qualified name of a class implementing {{Supplier}} needs to be given after "custom:". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:43:00 2017 From: issues at jboss.org (Sande Gilda (JIRA)) Date: Thu, 2 Mar 2017 12:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8282) Review & update ejb-multi-server documents In-Reply-To: References: Message-ID: Sande Gilda created WFLY-8282: --------------------------------- Summary: Review & update ejb-multi-server documents Key: WFLY-8282 URL: https://issues.jboss.org/browse/WFLY-8282 Project: WildFly Issue Type: Enhancement Components: Quickstarts Reporter: Sande Gilda Assignee: Sande Gilda Currently it references bunch of warnings / errors with its jiras. But those jiras ware fixed and there is no need to keep that in docs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:50:01 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Thu, 2 Mar 2017 12:50:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8186) CS tool, can't list --help without NPE occurence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Skopek resolved WFLY-8186. -------------------------------- Resolution: Done resolved as side effect of different change > CS tool, can't list --help without NPE occurence > ------------------------------------------------ > > Key: WFLY-8186 > URL: https://issues.jboss.org/browse/WFLY-8186 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store > > {code} > java -jar wildfly-elytron-tool.jar credential-store -h > {code} > or because of WFLY-8176 > {code} > java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230 > {code} > leads to > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store > -a | -e | -h | -r | -v [-c] [-f] [-i > ] [-l ] [-p ] [-s ] [-t ] [-u ] [-x > ] > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 12:50:01 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Thu, 2 Mar 2017 12:50:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8186) CS tool, can't list --help without NPE occurence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Skopek reassigned WFLY-8186: ---------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > CS tool, can't list --help without NPE occurence > ------------------------------------------------ > > Key: WFLY-8186 > URL: https://issues.jboss.org/browse/WFLY-8186 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Peter Skopek > Priority: Critical > Labels: credential-store > > {code} > java -jar wildfly-elytron-tool.jar credential-store -h > {code} > or because of WFLY-8176 > {code} > java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230 > {code} > leads to > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store > -a | -e | -h | -r | -v [-c] [-f] [-i > ] [-l ] [-p ] [-s ] [-t ] [-u ] [-x > ] > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 13:24:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 13:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-984) Bring dependency versions up to date with WildFly Core and WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned ELY-984: ------------------------------------ Assignee: Darran Lofthouse > Bring dependency versions up to date with WildFly Core and WildFly > ------------------------------------------------------------------ > > Key: ELY-984 > URL: https://issues.jboss.org/browse/ELY-984 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta28 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 13:30:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 13:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-985) Release WildFly Elytron 1.1.0.Beta28 In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-985: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta28 Key: ELY-985 URL: https://issues.jboss.org/browse/ELY-985 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta28 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 13:52:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 13:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2353) Upgrade WildFly Elytron to 1.1.0.Beta28 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2353: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta28 Key: WFCORE-2353 URL: https://issues.jboss.org/browse/WFCORE-2353 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta7 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 13:53:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 13:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2354) Upgrade Elytron Web to 1.0.0.Beta13 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2354: ---------------------------------------- Summary: Upgrade Elytron Web to 1.0.0.Beta13 Key: WFCORE-2354 URL: https://issues.jboss.org/browse/WFCORE-2354 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta7 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 13:54:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 13:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2355) Upgrade wildfly-elytron-tool to 1.0.0.Alpha3 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2355: ---------------------------------------- Summary: Upgrade wildfly-elytron-tool to 1.0.0.Alpha3 Key: WFCORE-2355 URL: https://issues.jboss.org/browse/WFCORE-2355 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta7 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 13:57:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 13:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8283) Upgrade Elytron Subsystem to 1.0.0.Beta11 In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8283: -------------------------------------- Summary: Upgrade Elytron Subsystem to 1.0.0.Beta11 Key: WFLY-8283 URL: https://issues.jboss.org/browse/WFLY-8283 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:02 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-984) Bring dependency versions up to date with WildFly Core and WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-984. ---------------------------------- Resolution: Done > Bring dependency versions up to date with WildFly Core and WildFly > ------------------------------------------------------------------ > > Key: ELY-984 > URL: https://issues.jboss.org/browse/ELY-984 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta28 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-952) Any events send to an AuditEndpoint after it is closed need to raise an error. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-952: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Any events send to an AuditEndpoint after it is closed need to raise an error. > ------------------------------------------------------------------------------ > > Key: ELY-952 > URL: https://issues.jboss.org/browse/ELY-952 > Project: WildFly Elytron > Issue Type: Bug > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Presently events could be dropped. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-949) Add a mechanism to assign priorities to audit events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-949: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add a mechanism to assign priorities to audit events > ---------------------------------------------------- > > Key: ELY-949 > URL: https://issues.jboss.org/browse/ELY-949 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > We probably want something like MatchRule but also need to think about how it will be configured. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-948) Add additional audit events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-948: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add additional audit events > --------------------------- > > Key: ELY-948 > URL: https://issues.jboss.org/browse/ELY-948 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-985) Release WildFly Elytron 1.1.0.Beta28 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-985. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta28 > ------------------------------------ > > Key: ELY-985 > URL: https://issues.jboss.org/browse/ELY-985 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta28 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-950) Add local audit log rotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-950: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add local audit log rotation > ---------------------------- > > Key: ELY-950 > URL: https://issues.jboss.org/browse/ELY-950 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Could be by time, size, rotate on start-up or a combination. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-951) Event handling queues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-951: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Event handling queues > --------------------- > > Key: ELY-951 > URL: https://issues.jboss.org/browse/ELY-951 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Currently audit events are handled synchronously which may be desirable to ensure events are logged. > However this does risk performance so queuing of events may also be desirable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within HTTP API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-942: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Review all method names within HTTP API > --------------------------------------- > > Key: ELY-942 > URL: https://issues.jboss.org/browse/ELY-942 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > This is a generic HTTP authentication framework not a Servlet authentication framework so should double check the naming is consistent with regards to the HTTP specifications not Servlet. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a CallbackHandler to the CredentialSources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-930: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Support appending a CallbackHandler to the CredentialSources > ------------------------------------------------------------ > > Key: ELY-930 > URL: https://issues.jboss.org/browse/ELY-930 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication client should not mandate an input source In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-938: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > KeyStore in authentication client should not mandate an input source > -------------------------------------------------------------------- > > Key: ELY-938 > URL: https://issues.jboss.org/browse/ELY-938 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > > Some keystores such as PKCS#11 are initialised without an InputStream. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of CLIENT_CERT authentication for SASL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-936: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Complete equivalent of CLIENT_CERT authentication for SASL > ---------------------------------------------------------- > > Key: ELY-936 > URL: https://issues.jboss.org/browse/ELY-936 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > This will likely extend outside of Elytron but track it here first. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration uniqueness enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-929: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > AuthenticationConfiguration uniqueness enhancements > --------------------------------------------------- > > Key: ELY-929 > URL: https://issues.jboss.org/browse/ELY-929 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta29 > > > Apply some enhancements to AuthenticationConfiguration uniqueness. > * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler > The following also may be possible and useful: > * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}} > * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier}}, or a {{Function References: Message-ID: [ https://issues.jboss.org/browse/ELY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-939: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > We need to be able to support standard KeyManager instances > ----------------------------------------------------------- > > Key: ELY-939 > URL: https://issues.jboss.org/browse/ELY-939 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > When using PKCS#11 we should not assume we can manipulate the private keys etc.. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6 Address Handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-887: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > AuthenticationContext IPv6 Address Handling > ------------------------------------------- > > Key: ELY-887 > URL: https://issues.jboss.org/browse/ELY-887 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > Within authentication client we need to ensure we are handling IPv6 addresses correctly. > Especially considering an equivalent IPv6 address can have more than one String representation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication client has no trust configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-937: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > SSLContext in authentication client has no trust configuration > -------------------------------------------------------------- > > Key: ELY-937 > URL: https://issues.jboss.org/browse/ELY-937 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > Currently it requires on the system default so it is not possible to configure trusted certificate authorities. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing without jboss-modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-873: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > AuthenticationClient testing without jboss-modules > -------------------------------------------------- > > Key: ELY-873 > URL: https://issues.jboss.org/browse/ELY-873 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Keeping AuthenticationClient usable without a dependency on JBoss Modules is the kind of thing that will be easy to break. > We should probably have a matrix of tests verifying AuthenticationClient anyway, we should then repeat the tests without JBoss Modules on the ClassPath. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in CredentialStore with JDK-8005408 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-926: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > PKCS#12 support in CredentialStore with JDK-8005408 > --------------------------------------------------- > > Key: ELY-926 > URL: https://issues.jboss.org/browse/ELY-926 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Environment: JDK with JDK-8005408 > Reporter: Zoran Regvart > Assignee: Zoran Regvart > Priority: Minor > Fix For: 1.1.0.Beta29 > > > JDK with [JDK-8005408|http://bugs.java.com/view_bug.do?bug_id=8005408] changed the behaviour of PKCS#12 KeyStore so it will use SecretKeyFactory to convert from SecretKeySpec to SecretKey. So a SecretKeyFactorySpi implementation is needed to support PKCS#7 Data OID used when storing data as SecretKeys in the PKCS#12 KeyStore. > This relates to ELY-920 and the test failure on JDK 1.8.0_74. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must handle BearerTokenCredential only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-853: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > OAuth2CredentialSource must handle BearerTokenCredential only > ------------------------------------------------------------- > > Key: ELY-853 > URL: https://issues.jboss.org/browse/ELY-853 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.1.0.Beta18 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration from SecurityFactory to CredentialSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-822: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Move MechanismConfiguration from SecurityFactory to CredentialSource > -------------------------------------------------------------------------------- > > Key: ELY-822 > URL: https://issues.jboss.org/browse/ELY-822 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > This will make it consistent with client side configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling of isComplete() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-770: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Review SASL mechanism handling of isComplete() > ---------------------------------------------- > > Key: ELY-770 > URL: https://issues.jboss.org/browse/ELY-770 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > > The javadoc of the isComplete() method states: - > _Determines whether the authentication exchange has completed. This method is typically called after each invocation of evaluateResponse() to determine whether the authentication has completed successfully or should be continued._ > Also getAuthorizationID() states: - > _Reports the authorization ID in effect for the client of this session. This method can only be called if isComplete() returns true. > _ > Although the former is very vague there just seem to be a suggestion that complete means successfully complete, our mechs are setting complete very early and other wrappers such as AuthenticationCompleteCallbackSaslServerFactory are using complete as a flag to report failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper implementation. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-889: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add a filtering RoleMapper implementation. > ------------------------------------------ > > Key: ELY-889 > URL: https://issues.jboss.org/browse/ELY-889 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Utils > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > The RoleMapper APIs are built around querying one role at a time, however at times it may be desirable to obtain a set of roles an identity is a member of. > To avoid iterating every role which depending on the configuration could be thousands backed by a remote store we should have a FilteringRoleMapper implementation that will allow any checks and iteration of the roles to be restricted to a finite set of acceptable roles. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible for "anonymous" identity In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-861: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Role assignment not possible for "anonymous" identity > ----------------------------------------------------- > > Key: ELY-861 > URL: https://issues.jboss.org/browse/ELY-861 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-773: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier > ------------------------------------------------------------------------------------------------------------ > > Key: ELY-773 > URL: https://issues.jboss.org/browse/ELY-773 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta29 > > > This may be obsoleted by ongoing work but just wanted an issue to track where AuthenticationConfiguration and related classes currently uses PaswordFactory.getInstance without passing in a Supplier for Provider[]. > * SetCredentialsConfiguration > * SetKeyStoreCredentialAuthenticationConfiguration > * ElytronAuthenticator > * ElytronXmlParser. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing authorization and mechanism information In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-854: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > OAuth2SaslServer is missing authorization and mechanism information > ------------------------------------------------------------------- > > Key: ELY-854 > URL: https://issues.jboss.org/browse/ELY-854 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.1.0.Beta18 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-765) ServiceLoader Provider and SaslClientFactory discovery should be able to use system ClassLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-765: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > ServiceLoader Provider and SaslClientFactory discovery should be able to use system ClassLoader > ----------------------------------------------------------------------------------------------- > > Key: ELY-765 > URL: https://issues.jboss.org/browse/ELY-765 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Clients may not be running using a JBoss Modules ClassLoader. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around CredentialSource style storage capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-810: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Unify CredentialStore around CredentialSource style storage capability > ---------------------------------------------------------------------- > > Key: ELY-810 > URL: https://issues.jboss.org/browse/ELY-810 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta29 > > > The following needs to be done: > * Move the PB masked password format to a proper password type > * Introduce protection parameters for credential stores and entries > * Drop the admin_key concept in favor of credential store protection parameters > * Introduce a proper vault-compatible credential store > * Introduce a mechanism to pull protection parameters for stores from the client configuration > * Use a credential store which can store (nearly) any credential type > * Update XML accordingly > * Remove dangerous command execution patterns from credential store, make them safe and make them CredentialSources instead > * Clean up exception hierarchy of credential stores > * Introduce simple map-backed credential store > Additionally, the above implies: > * Introduce AlgorithmParameterSpi for password parameter types > * Introduce hashing ability for parameters > * Add missing parameter types for PBE > * Introduce serialization trickery to support picketbox class names for vault files > * Atomic file output stream > * Update tests as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-849: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Rename setMechanismProperties to setSaslMechanismProperties > ----------------------------------------------------------- > > Key: ELY-849 > URL: https://issues.jboss.org/browse/ELY-849 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties. > We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-838: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore interaction from within SASL mechanisms. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-662: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Eliminate CredentialStore interaction from within SASL mechanisms. > ------------------------------------------------------------------ > > Key: ELY-662 > URL: https://issues.jboss.org/browse/ELY-662 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store, SASL > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Priority: Critical > Fix For: 1.1.0.Beta29 > > > The conversion between callbacks and credential store should be handled centrally within the callback handler and not within the mechanism. > This way all mechanisms can use the core integration including mechanisms that may not be Elytron aware just using standard Java callbacks. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is SSLContextAuthenticationConfiguration Still required now sslRules are separated. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-747: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Is SSLContextAuthenticationConfiguration Still required now sslRules are separated. > ----------------------------------------------------------------------------------- > > Key: ELY-747 > URL: https://issues.jboss.org/browse/ELY-747 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-728: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. > ------------------------------------------------------------------------------------------ > > Key: ELY-728 > URL: https://issues.jboss.org/browse/ELY-728 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, Realms > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > > This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from generated javadoc. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-681: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Hide private packages from generated javadoc. > --------------------------------------------- > > Key: ELY-681 > URL: https://issues.jboss.org/browse/ELY-681 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > > We may want two profiles so we can generate a full javadoc and a 'public' javadoc. > The 'public' javadoc should be the default one generated and should exclude the following packages: - > org.wildfly.security._private > org.wildfly.security.asn1 > org.wildfly.security.auth.realm > org.wildfly.security.auth.realm.* > org.wildfly.security.authz.jacc > org.wildfly.security.credential.store.impl > org.wildfly.security.security.digest > org.wildfly.security.http.impl > org.wildfly.security.security.keystore > org.wildfly.security.mechanism.oauth2 > org.wildfly.security.mechanism.scram > org.wildfly.security.password.impl > org.wildfly.security.password.util > org.wildfly.security.pem > org.wildfly.security.sasl > org.wildfly.security.sasl.* (Except util) > org.wildfly.security.util > org.wildfly.security.util_private > org.wildfly.security.x500 > org.wildfly.security.x500.cert -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering Implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-726: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Default Mechanism Ordering Implementation > ----------------------------------------- > > Key: ELY-726 > URL: https://issues.jboss.org/browse/ELY-726 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > We have to have some form of mechanism ordering anyway to get silent mechanisms to the front of the queue. > SaslMechanismInformation may need some updates but we have plenty of information about the mechanisms so we should be able to put together a reasonable documented ordering. > Stronger mechanisms that can complete without interaction with the client can be pulled up the list as they can quickly silently fail where AuthenticationClient does not have enough information to handle them. This set probably includes JBOSS_LOCAL_USER, EXTERNAL, GSSAPI, GS2, and the token mechs. > For username / password mechanisms we can ensure PLAIN goes last. > Of the CRAM, Digest, and SCRAM set I would suggest first order by digest algorithm and then SCRAM -> Digest -> CRAM. > There will be the opportunity for plenty of discussions on is X really better than Y but I think a reasonable default implementation that is documented will be much better than today's current random ordering. Once filtering has been applied to take into account things like available credentials in the realms etc. > I would expect most lists to be very small, maybe some silent mechs a token mech and one or two username / password mechs depending on consistency of an identity store. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-722) Move callback handler interactions to a common base class for HTTP mechanisms, . In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-722: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Move callback handler interactions to a common base class for HTTP mechanisms,. > ------------------------------------------------------------------------------- > > Key: ELY-722 > URL: https://issues.jboss.org/browse/ELY-722 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > This is to follow a similar pattern as is used for the SASL mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to be optionally passed a Supplier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-774: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > KeystorePasswordStore needs to be optionally passed a Supplier > -------------------------------------------------------------------------- > > Key: ELY-774 > URL: https://issues.jboss.org/browse/ELY-774 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 1.1.0.Beta29 > > > The current implementation assumes it is globally registered but we may want a configuration without global registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism implementations final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-659: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Make all mechanism implementations final > ---------------------------------------- > > Key: ELY-659 > URL: https://issues.jboss.org/browse/ELY-659 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms, HTTP, SASL > Reporter: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta29 > > > It is very important to make all the mechanism implementations final. Relatedly, they should have no protected members. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-601: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema > ------------------------------------------------------------------------------------- > > Key: ELY-601 > URL: https://issues.jboss.org/browse/ELY-601 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > > Within the schema a lot of these are configured using 'set'*' elements - switch the methods over to set as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-609: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta29 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-613: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Some nested classes should be considered to be static nested in Elytron > ----------------------------------------------------------------------- > > Key: ELY-613 > URL: https://issues.jboss.org/browse/ELY-613 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta29 > > > There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered: > * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm > * DecoderState from org.wildfly.security.asn1.DERDecoder > * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm > * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm > * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-766) It should be possible for domains to be configured with a list of other domains to proactively outflow to. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-766: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > It should be possible for domains to be configured with a list of other domains to proactively outflow to. > ---------------------------------------------------------------------------------------------------------- > > Key: ELY-766 > URL: https://issues.jboss.org/browse/ELY-766 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication should forward authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-559: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Token-based authentication should forward authentication > -------------------------------------------------------- > > Key: ELY-559 > URL: https://issues.jboss.org/browse/ELY-559 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Mechanisms > Reporter: David Lloyd > Fix For: 1.1.0.Beta29 > > > Mechanisms that handle BearerTokenCredetials (ELY-557) should forward them as public or private credentials (ELY-473 / https://github.com/wildfly-security/wildfly-elytron/pull/434 ). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication trigger SSLSession renegotiation? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-621: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Client Cert authentication trigger SSLSession renegotiation? > ------------------------------------------------------------ > > Key: ELY-621 > URL: https://issues.jboss.org/browse/ELY-621 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > This could be an option to enable demanding client verification for an established connection but depending on the application being accessed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-617: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration > --------------------------------------------------------------------------------- > > Key: ELY-617 > URL: https://issues.jboss.org/browse/ELY-617 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Javadoc states various NameRewriter instances will not be null, implementation suggests otherwise. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-639: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > SecurityIdentity and PeerIdentity should have more runAs* variants > ------------------------------------------------------------------ > > Key: ELY-639 > URL: https://issues.jboss.org/browse/ELY-639 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Fix For: 1.1.0.Beta29 > > > The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-600) Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-600: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. > --------------------------------------------------------------------------------- > > Key: ELY-600 > URL: https://issues.jboss.org/browse/ELY-600 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-486: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages. > ------------------------------------------------------------------------------- > > Key: ELY-486 > URL: https://issues.jboss.org/browse/ELY-486 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-485) Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-485: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages. > -------------------------------------------------------------------------------- > > Key: ELY-485 > URL: https://issues.jboss.org/browse/ELY-485 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-489: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages. > ------------------------------------------------------------------------------ > > Key: ELY-489 > URL: https://issues.jboss.org/browse/ELY-489 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to Elytron client configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-449: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add CredentialStore support to Elytron client configuration > ----------------------------------------------------------- > > Key: ELY-449 > URL: https://issues.jboss.org/browse/ELY-449 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client, Credential Store > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-298: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > load-from/uri keystore xsd/parser mismatch > ------------------------------------------ > > Key: ELY-298 > URL: https://issues.jboss.org/browse/ELY-298 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > The xsd has > {code} > > > > > > > > {code} > The parser seems to look for 'uri' rather than 'load-from' -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-211: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Client-side trust store configuration > ------------------------------------- > > Key: ELY-211 > URL: https://issues.jboss.org/browse/ELY-211 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta29 > > > Lest I forget. The client needs the ability to supplement the default trust store, to restrict the set of acceptable peer certificates/signers, for mutual authentication purposes. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-477) XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-477: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK > ---------------------------------------------------------- > > Key: ELY-477 > URL: https://issues.jboss.org/browse/ELY-477 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.1.0.Beta4 > Reporter: Ondrej Lukas > Fix For: 1.1.0.Beta29 > > > Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with: > {code} > expected:<-1> but was:<7> > and stacktrace: > java.lang.AssertionError: expected:<-1> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96) > ... > {code} > It is caused by undefined line number of XML parsing failure for IBM JDK. > Stacktrace of checked XMLStreamException for IBM JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} > Stacktrace of checked XMLStreamException for Oracle JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml:7:39: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-181: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Review JACC in Servlet and EJB subsystems > ----------------------------------------- > > Key: ELY-181 > URL: https://issues.jboss.org/browse/ELY-181 > Project: WildFly Elytron > Issue Type: Sub-task > Components: API / SPI > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:08 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-455: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > OAuth2 Credential Store > ----------------------- > > Key: ELY-455 > URL: https://issues.jboss.org/browse/ELY-455 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Reporter: David Lloyd > Assignee: Pedro Igor > Fix For: 1.1.0.Beta29 > > > Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-595: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded. > ------------------------------------------------------------------------------------------------------ > > Key: ELY-595 > URL: https://issues.jboss.org/browse/ELY-595 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-524: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > RealmIdentity data caching support in the LDAP realm > ---------------------------------------------------- > > Key: ELY-524 > URL: https://issues.jboss.org/browse/ELY-524 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: David Lloyd > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta29 > > > The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic. > The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention. > For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes. > Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name. > This is a complex design topic so discussion is welcome. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:28:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-490: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta28) > Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. > ------------------------------------------------------------------------ > > Key: ELY-490 > URL: https://issues.jboss.org/browse/ELY-490 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:52:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to Elytron client configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned ELY-449: ------------------------------------ Fix Version/s: 1.1.0.Beta17 (was: 1.1.0.Beta29) Assignee: Peter Skopek Resolution: Done > Add CredentialStore support to Elytron client configuration > ----------------------------------------------------------- > > Key: ELY-449 > URL: https://issues.jboss.org/browse/ELY-449 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client, Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 1.1.0.Beta17 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:57:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned ELY-838: ------------------------------------ Assignee: David Lloyd > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta29 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:57:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore interaction from within SASL mechanisms. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-662. ---------------------------------- Resolution: Out of Date Mechanism and credential store interaction has been cleaned up. > Eliminate CredentialStore interaction from within SASL mechanisms. > ------------------------------------------------------------------ > > Key: ELY-662 > URL: https://issues.jboss.org/browse/ELY-662 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store, SASL > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Priority: Critical > Fix For: 1.1.0.Beta29 > > > The conversion between callbacks and credential store should be handled centrally within the callback handler and not within the mechanism. > This way all mechanisms can use the core integration including mechanisms that may not be Elytron aware just using standard Java callbacks. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:59:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-838. ---------------------------------- Fix Version/s: 1.1.0.Beta4 Assignee: Farah Juma (was: David Lloyd) Resolution: Done > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Farah Juma > Priority: Critical > Fix For: 1.1.0.Beta29, 1.1.0.Beta4 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 14:59:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 2 Mar 2017 14:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-838: --------------------------------- Fix Version/s: (was: 1.1.0.Beta29) > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Farah Juma > Priority: Critical > Fix For: 1.1.0.Beta4 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 16:47:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 2 Mar 2017 16:47:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro reassigned WFLY-3858: ---------------------------------- Assignee: Paul Ferraro (was: Bartosz Spyrko-?mietanko) > Infinispan cache configuration is not always applied to security-domain > ----------------------------------------------------------------------- > > Key: WFLY-3858 > URL: https://issues.jboss.org/browse/WFLY-3858 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Robert Tuck > Assignee: Paul Ferraro > Attachments: debugger output.txt > > > On Wildfly 8.1.0.Final, I have the following standalone-ha.xml: > > ... > > > > > > > > > ... > > > ... > > > module="deployment.ewb-server-ear.ear"> > > > > > > > > After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries. > After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement: > public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception { > log.debugf("Creating SDC for domain=" + securityDomain); > AuthenticationManager am = createAuthenticationManager(securityDomain); > // create authentication cache > if (cacheFactory instanceof EmbeddedCacheManager) { > EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory); > @SuppressWarnings("rawtypes") > Cache cache = null; > if (cacheManager != null) { > // TODO override global settings with security domain specific > ConfigurationBuilder builder = new ConfigurationBuilder(); > Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache"); > ^^^^ This call here doesn?t always return the correct configuration, baseCfg is then null. > if (baseCfg != null) { > builder.read(baseCfg); > } > cacheManager.defineConfiguration(securityDomain, builder.build()); > cache = cacheManager.getCache(securityDomain); > } > if (cache != null && am instanceof CacheableManager) { > @SuppressWarnings({ "unchecked", "rawtypes" }) > CacheableManager cm = (CacheableManager) am; > cm.setCache(cache); > } > } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) { > > } > getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager: > @Override > public Configuration getCacheConfiguration(String name) { > Configuration configuration = configurationOverrides.get(name); > if (configuration == null && cacheExists(name)) { > return defaultConfiguration; > } > return configuration; > } > Seems like the condition configuration == null occurs when the cache doesn?t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String). > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 20:40:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 2 Mar 2017 20:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8284) Wildfly HTTP Client 1.0.0.Alpha3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9269 to WFLY-8284: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8284 (was: JBEAP-9269) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Wildfly HTTP Client 1.0.0.Alpha3 > -------------------------------- > > Key: WFLY-8284 > URL: https://issues.jboss.org/browse/WFLY-8284 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 20:40:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 2 Mar 2017 20:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8284) Wildfly HTTP Client 1.0.0.Alpha3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas reassigned WFLY-8284: ------------------------------------ Assignee: Stuart Douglas > Wildfly HTTP Client 1.0.0.Alpha3 > -------------------------------- > > Key: WFLY-8284 > URL: https://issues.jboss.org/browse/WFLY-8284 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 21:07:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 2 Mar 2017 21:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2356) Failure in a step ResultHandler should not always be reported as occurring during rollback In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2356: ---------------------------------------- Summary: Failure in a step ResultHandler should not always be reported as occurring during rollback Key: WFCORE-2356 URL: https://issues.jboss.org/browse/WFCORE-2356 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Priority: Minor When AbstractOperationContext.Step invokes a ResultHandler it catches and logs any exception. But the logged message states that the catch was during rollback handling. When the code was first written, perhaps the catch block was only for rollback handling, but now it handles both rollback and completion of successful ops. So the log message needs to be accurate. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 23:38:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 2 Mar 2017 23:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) Perform and document a small load test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-47: ------------------------------------- Assignee: viet nguyen (was: mfoley user) > Perform and document a small load test run > ------------------------------------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 23:44:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 2 Mar 2017 23:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-52: ------------------------------------- Summary: Create a load generator Key: HAWKULARQE-52 URL: https://issues.jboss.org/browse/HAWKULARQE-52 Project: Hawkular QE Issue Type: Sub-task Reporter: viet nguyen Assignee: mfoley user I'm building a load generator app with the following features: 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram 2. Runable as an OpenShift pod with required mapconfig for HOSA 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 23:46:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 2 Mar 2017 23:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-53) Validation queries In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-53: ------------------------------------- Summary: Validation queries Key: HAWKULARQE-53 URL: https://issues.jboss.org/browse/HAWKULARQE-53 Project: Hawkular QE Issue Type: Sub-task Reporter: viet nguyen Assignee: mfoley user Create some sort of report to show metrics generated by HOSA -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 23:46:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 2 Mar 2017 23:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-52: ------------------------------------- Assignee: viet nguyen (was: mfoley user) > Create a load generator > ----------------------- > > Key: HAWKULARQE-52 > URL: https://issues.jboss.org/browse/HAWKULARQE-52 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > I'm building a load generator app with the following features: > 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram > 2. Runable as an OpenShift pod with required mapconfig for HOSA > 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 23:46:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 2 Mar 2017 23:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-53) Validation queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-53: ------------------------------------- Assignee: viet nguyen (was: mfoley user) > Validation queries > ------------------ > > Key: HAWKULARQE-53 > URL: https://issues.jboss.org/browse/HAWKULARQE-53 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Create some sort of report to show metrics generated by HOSA -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 23:47:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 2 Mar 2017 23:47:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371889#comment-13371889 ] viet nguyen commented on HAWKULARQE-52: --------------------------------------- WIP: https://github.com/vnugent/promgen > Create a load generator > ----------------------- > > Key: HAWKULARQE-52 > URL: https://issues.jboss.org/browse/HAWKULARQE-52 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > I'm building a load generator app with the following features: > 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram > 2. Runable as an OpenShift pod with required mapconfig for HOSA > 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 02:23:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 02:23:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-986) Method equals for MatchRule throws java.lang.IllegalStateException In-Reply-To: References: Message-ID: Ondrej Lukas created ELY-986: -------------------------------- Summary: Method equals for MatchRule throws java.lang.IllegalStateException Key: ELY-986 URL: https://issues.jboss.org/browse/ELY-986 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when method {{equals(MatchRule other)}} is called on {{org.wildfly.security.auth.client.MatchRule}} then it finishes with java.lang.IllegalStateException with following stack trace, for calling {{MatchRule.ALL.equals(MatchRule.ALL);}}: {code} java.lang.IllegalStateException at org.wildfly.security.auth.client.MatchRule$1.getMatchUser(MatchRule.java:102) at org.wildfly.security.auth.client.MatchRule.getMatchUser(MatchRule.java:500) at org.wildfly.security.auth.client.MatchNoUserRule.halfEqual(MatchNoUserRule.java:46) at org.wildfly.security.auth.client.MatchRule.equals(MatchRule.java:157) ... {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 02:24:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 02:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-986) Method equals for MatchRule throws java.lang.IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated ELY-986: ----------------------------- Affects Version/s: 1.1.0.Beta28 > Method equals for MatchRule throws java.lang.IllegalStateException > ------------------------------------------------------------------ > > Key: ELY-986 > URL: https://issues.jboss.org/browse/ELY-986 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In case when method {{equals(MatchRule other)}} is called on {{org.wildfly.security.auth.client.MatchRule}} then it finishes with java.lang.IllegalStateException with following stack trace, for calling {{MatchRule.ALL.equals(MatchRule.ALL);}}: > {code} > java.lang.IllegalStateException > at org.wildfly.security.auth.client.MatchRule$1.getMatchUser(MatchRule.java:102) > at org.wildfly.security.auth.client.MatchRule.getMatchUser(MatchRule.java:500) > at org.wildfly.security.auth.client.MatchNoUserRule.halfEqual(MatchNoUserRule.java:46) > at org.wildfly.security.auth.client.MatchRule.equals(MatchRule.java:157) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 02:55:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 3 Mar 2017 02:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-36) IPV6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-36: ---------------------------------------- Assignee: Hayk Hovsepyan (was: mfoley user) > IPV6 > ---- > > Key: HAWKULARQE-36 > URL: https://issues.jboss.org/browse/HAWKULARQE-36 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > See: [HAWKULAR-1193|https://issues.jboss.org/browse/HAWKULAR-1193] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:25:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 3 Mar 2017 03:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7983) Credential store file isn't created when we add there new entry in embed-server mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFLY-7983: ------------------------------- Description: Credential store file isn't created when we add there new entry in embed-server mode. * ./bin/jboss-cli.sh * embed-server * /subsystem=elytron/credential-store=store001:add(uri="cr-store://test/store001.jceks?create=true", credential-reference={clear-text=pass123}) * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) store001.jceks file should be created in JBOSS_HOME directory, but it doesn't. When I stop embedded server and start standalone server everything work fine. * stop-embedded-server * ./bin/standalone.sh * connect * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) store001.jceks file is correctly created in JBOSS_HOME directory. *NOTE:* When I copy there store001.jceks file to JBOSS_HOME directory with same password to access as expected then entry is added correctly. was: Credential store file isn't created when we add there new entry in embed-server mode. * ./bin/jboss-cli.sh * embed-server * /subsystem=elytron/credential-store=store001:add(uri="cr-store://test/store001.jceks?create.storage=true", credential-reference={clear-text=pass123}) * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) store001.jceks file should be created in JBOSS_HOME directory, but it doesn't. When I stop embedded server and start standalone server everything work fine. * stop-embedded-server * ./bin/standalone.sh * connect * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) store001.jceks file is correctly created in JBOSS_HOME directory. *NOTE:* When I copy there store001.jceks file to JBOSS_HOME directory with same password to access as expected then entry is added correctly. > Credential store file isn't created when we add there new entry in embed-server mode. > ------------------------------------------------------------------------------------- > > Key: WFLY-7983 > URL: https://issues.jboss.org/browse/WFLY-7983 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Credential store file isn't created when we add there new entry in embed-server mode. > * ./bin/jboss-cli.sh > * embed-server > * /subsystem=elytron/credential-store=store001:add(uri="cr-store://test/store001.jceks?create=true", credential-reference={clear-text=pass123}) > * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) > store001.jceks file should be created in JBOSS_HOME directory, but it doesn't. > When I stop embedded server and start standalone server everything work fine. > * stop-embedded-server > * ./bin/standalone.sh > * connect > * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) > store001.jceks file is correctly created in JBOSS_HOME directory. > *NOTE:* > When I copy there store001.jceks file to JBOSS_HOME directory with same password to access as expected then entry is added correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:28:01 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 3 Mar 2017 03:28:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371932#comment-13371932 ] Tomas Hofman commented on WFLY-8238: ------------------------------------ It seems activemq attributes were set this way from the beginning. I think the current solution is satisfactory as it doesn't change current behaviour concerning which attributes must be set during resource creation, and it fixes the weird issues, like that once an attributes was written to, it couldn't be undefined. > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:30:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 3 Mar 2017 03:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371934#comment-13371934 ] Tomas Hofman commented on WFLY-8238: ------------------------------------ Except the failing tests, investigating. > Unable to undefine credential-reference > --------------------------------------- > > Key: WFLY-8238 > URL: https://issues.jboss.org/browse/WFLY-8238 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Claudio Miranda > Assignee: Tomas Hofman > > A bridge is added and a credential-reference is set. > However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value. > Also neither credential-reference and password are required=true, so they may be undefined. > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1}) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} > The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference > {code} > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1) > /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:32:03 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 3 Mar 2017 03:32:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7983) Credential store file isn't created when we add there new entry in embed-server mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371937#comment-13371937 ] Hynek ?v?bek commented on WFLY-7983: ------------------------------------ The problem is gone in EAP7.1.0.DR12 and EAP7.1.0.DR13. > Credential store file isn't created when we add there new entry in embed-server mode. > ------------------------------------------------------------------------------------- > > Key: WFLY-7983 > URL: https://issues.jboss.org/browse/WFLY-7983 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Credential store file isn't created when we add there new entry in embed-server mode. > * ./bin/jboss-cli.sh > * embed-server > * /subsystem=elytron/credential-store=store001:add(uri="cr-store://test/store001.jceks?create=true", credential-reference={clear-text=pass123}) > * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) > store001.jceks file should be created in JBOSS_HOME directory, but it doesn't. > When I stop embedded server and start standalone server everything work fine. > * stop-embedded-server > * ./bin/standalone.sh > * connect > * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) > store001.jceks file is correctly created in JBOSS_HOME directory. > *NOTE:* > When I copy there store001.jceks file to JBOSS_HOME directory with same password to access as expected then entry is added correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:46:00 2017 From: issues at jboss.org (Anton Giertli (JIRA)) Date: Fri, 3 Mar 2017 03:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: Anton Giertli created DROOLS-1461: ------------------------------------- Summary: In operator doesn't work with variable Key: DROOLS-1461 URL: https://issues.jboss.org/browse/DROOLS-1461 Project: Drools Issue Type: Bug Reporter: Anton Giertli Assignee: Edson Tirelli Attachments: operators.zip This works just fine: {code:java} rule "checkFirstName" dialect "mvel" when Message( message in ( "anton","giertli") ) then System.out.println("LHS OK"); end {code} But rule like this, won't fire: global java.util.List $myGlobal; {code:java} rule "checkFirstName" dialect "mvel" when Message( message in ( $myGlobal) ) then System.out.println("LHS OK"); end {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:46:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 3 Mar 2017 03:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-1461: ----------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > global java.util.List $myGlobal; > > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:46:00 2017 From: issues at jboss.org (Anton Giertli (JIRA)) Date: Fri, 3 Mar 2017 03:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Giertli updated DROOLS-1461: ---------------------------------- Attachment: operators.zip > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > global java.util.List $myGlobal; > > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:46:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 3 Mar 2017 03:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco updated DROOLS-1461: -------------------------------- Component/s: core engine > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > global java.util.List $myGlobal; > > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:48:00 2017 From: issues at jboss.org (Anton Giertli (JIRA)) Date: Fri, 3 Mar 2017 03:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Giertli updated DROOLS-1461: ---------------------------------- Description: This works just fine: {code:java} rule "checkFirstName" dialect "mvel" when Message( message in ( "anton","giertli") ) then System.out.println("LHS OK"); end {code} But rule like this, won't fire: {code:java} global java.util.List $myGlobal; rule "checkFirstName" dialect "mvel" when Message( message in ( $myGlobal) ) then System.out.println("LHS OK"); end {code} was: This works just fine: {code:java} rule "checkFirstName" dialect "mvel" when Message( message in ( "anton","giertli") ) then System.out.println("LHS OK"); end {code} But rule like this, won't fire: global java.util.List $myGlobal; {code:java} rule "checkFirstName" dialect "mvel" when Message( message in ( $myGlobal) ) then System.out.println("LHS OK"); end {code} > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:55:03 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 03:55:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-987) Confusion in method with(AuthenticationContext other) in AuthenticationContext In-Reply-To: References: Message-ID: Ondrej Lukas created ELY-987: -------------------------------- Summary: Confusion in method with(AuthenticationContext other) in AuthenticationContext Key: ELY-987 URL: https://issues.jboss.org/browse/ELY-987 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical org.wildfly.security.auth.client.AuthenticationContext includes method {{AuthenticationContext with(AuthenticationContext other)}} which creates new AuthenticationContext which includes rules and configuration and SSL context of given AuthenticationContext other. However, in case when {{with}} method is used with index and another AuthenticationContext, then it includes only rules and configuration (SSL context is not used). There is also method {{withSsl}} which includes rules and SSL context, but no configuration. I see three problems here: * there is different behavior between {{with(AuthenticationContext other)}} and {{with(int idx, AuthenticationContext other)}} - first includes also SSL context * javadoc for with(AuthenticationContext other) does not describe that SSL context from given {{AuthenticationContext other}} is also used. * there is not able to include both configuration and SSL context into any AuthenticationContext on some position based on index I report this as critical because it is part of public API - it should stay backward compatible once it will be released. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:56:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 03:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-987) Confusion in method with(AuthenticationContext other) in AuthenticationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated ELY-987: ----------------------------- Affects Version/s: 1.1.0.Beta28 > Confusion in method with(AuthenticationContext other) in AuthenticationContext > ------------------------------------------------------------------------------ > > Key: ELY-987 > URL: https://issues.jboss.org/browse/ELY-987 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > org.wildfly.security.auth.client.AuthenticationContext includes method {{AuthenticationContext with(AuthenticationContext other)}} which creates new AuthenticationContext which includes rules and configuration and SSL context of given AuthenticationContext other. > However, in case when {{with}} method is used with index and another AuthenticationContext, then it includes only rules and configuration (SSL context is not used). There is also method {{withSsl}} which includes rules and SSL context, but no configuration. > I see three problems here: > * there is different behavior between {{with(AuthenticationContext other)}} and {{with(int idx, AuthenticationContext other)}} - first includes also SSL context > * javadoc for with(AuthenticationContext other) does not describe that SSL context from given {{AuthenticationContext other}} is also used. > * there is not able to include both configuration and SSL context into any AuthenticationContext on some position based on index > I report this as critical because it is part of public API - it should stay backward compatible once it will be released. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 03:56:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 3 Mar 2017 03:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1431) Make property reactivity active by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-1431: ----------------------------------- Assignee: Mario Fusco (was: Matteo Mortari) > Make property reactivity active by default > ------------------------------------------ > > Key: DROOLS-1431 > URL: https://issues.jboss.org/browse/DROOLS-1431 > Project: Drools > Issue Type: Enhancement > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 04:02:02 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 3 Mar 2017 04:02:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2357) RBAC: The two kinds of non-addressability In-Reply-To: References: Message-ID: Hynek ?v?bek created WFCORE-2357: ------------------------------------ Summary: RBAC: The two kinds of non-addressability Key: WFCORE-2357 URL: https://issues.jboss.org/browse/WFCORE-2357 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.Final Reporter: Hynek ?v?bek Assignee: Brian Stansberry Ever since we introduced RBAC in WildFly / EAP, we had this shortcut in place that we were documenting in EAP Release Notes: bq. Some resources are non-addressable to server-group and host scoped roles in order to provide a simplified view of the management model to improve usability. This is distinct from resources that are non-addressable to protect sensitive data. I think that this shortcut is in place mainly because HAL can't cope with addressable but non-readable resources, but there might be other reasons. In any case, I figured I should finally file an upstream JIRA so that I don't have to bug Brian all the time if this has changed :-) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 04:31:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Fri, 3 Mar 2017 04:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8285) Elytron, Can't access application secured with SPNEGO fallbacking to FORM In-Reply-To: References: Message-ID: Martin Choma created WFLY-8285: ---------------------------------- Summary: Elytron, Can't access application secured with SPNEGO fallbacking to FORM Key: WFLY-8285 URL: https://issues.jboss.org/browse/WFLY-8285 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker When accessing application configured with SPNEGO + FORM fallback, then user get 404 on first http GET. {code} [mchoma at localhost ~]$ curl -v http://localhost.localdomain:8080/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/SimpleSecuredServlet * Hostname was NOT found in DNS cache * Trying 127.0.0.1... * Connected to localhost.localdomain (127.0.0.1) port 8080 (#0) > GET /be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/SimpleSecuredServlet HTTP/1.1 > User-Agent: curl/7.37.0 > Host: localhost.localdomain:8080 > Accept: */* > < HTTP/1.1 404 Not Found < Expires: 0 < Cache-Control: no-cache, no-store, must-revalidate < X-Powered-By: Undertow/1 < Set-Cookie: JSESSIONID=0O3kk4WJTVuH0XuWriO_d_M6HMCb83Ri7UZmtUU0.localhost; path=/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5 * Server JBoss-EAP/7 is not blacklisted < Server: JBoss-EAP/7 < Pragma: no-cache < Date: Fri, 03 Mar 2017 09:15:41 GMT < Connection: keep-alive < WWW-Authenticate: Negotiate < Content-Type: text/html;charset=UTF-8 < Content-Length: 149 < * Connection #0 to host localhost.localdomain left intact Error/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/http:/localhost.localdomain:8080/login.jsp[mchoma at localhost ~]$ {code} Changing in web.xml {{SPNEGO,FORM}} to {{SPNEGO}} makes SPNEGO work again. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 04:56:00 2017 From: issues at jboss.org (Jim Ma (JIRA)) Date: Fri, 3 Mar 2017 04:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372022#comment-13372022 ] Jim Ma commented on WFLY-8160: ------------------------------ Hi [~maheshvizag], Can you please provide the other classes/test project that we can reproduce this issue locally ? What is your client code ? > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Priority: Blocker > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 05:09:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 3 Mar 2017 05:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372110#comment-13372110 ] Tomaz Cerar commented on WFLY-8160: ----------------------------------- Could you provide file leak track with help of http://file-leak-detector.kohsuke.org/ This will provide you with list of stacktraces where the file leaks are occuring and please paste that back here. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Priority: Blocker > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 05:13:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 3 Mar 2017 05:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-54) JDG integration into CFME In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-54: ---------------------------------------- Summary: JDG integration into CFME Key: HAWKULARQE-54 URL: https://issues.jboss.org/browse/HAWKULARQE-54 Project: Hawkular QE Issue Type: Task Environment: From Heiko's status email 02/02. Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Currently work is in progress for MiQ upstream. Further information about including in downstream later. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 05:52:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Fri, 3 Mar 2017 05:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2358) deployment-overlay link action help is not accurate In-Reply-To: References: Message-ID: Jean-Francois Denise created WFCORE-2358: -------------------------------------------- Summary: deployment-overlay link action help is not accurate Key: WFCORE-2358 URL: https://issues.jboss.org/browse/WFCORE-2358 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Priority: Minor Deployment can be created after being linked to the overlay. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 06:11:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 3 Mar 2017 06:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-55) CFME Tests: Adjust environment and smoke tests to JMAN4-111 In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-55: ---------------------------------------- Summary: CFME Tests: Adjust environment and smoke tests to JMAN4-111 Key: HAWKULARQE-55 URL: https://issues.jboss.org/browse/HAWKULARQE-55 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Priority: Blocker Once [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] feature is done, EAP servers on Containers will become immutable, but our CFME Testing environment runs on Containers. * switch EAP7 Containers to VMs * and for container EAP7 make smoke tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 06:37:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 3 Mar 2017 06:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2352) Migrate the WildFly Elytron subsystem to WildFly Core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2352: ------------------------------------- Priority: Critical (was: Major) > Migrate the WildFly Elytron subsystem to WildFly Core > ----------------------------------------------------- > > Key: WFCORE-2352 > URL: https://issues.jboss.org/browse/WFCORE-2352 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta7 > > > This task is to move the subsystem to WildFly Core. This task is not to add the subsystem to any additional feature packs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 06:52:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Fri, 3 Mar 2017 06:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Mortari updated DROOLS-1461: ----------------------------------- Attachment: screenshot-1.png > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip, screenshot-1.png > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 07:01:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Fri, 3 Mar 2017 07:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372204#comment-13372204 ] Matteo Mortari commented on DROOLS-1461: ---------------------------------------- I'm also voting for close/reject this issue, as the second rule in the description has a different semantic than what intended by the reporter, I think. The second rule semantic means, check {{message}} is contained {{in}} the elements within the round parenthesis. Now the message property (String) is NOT contained in the set of elements contaning 1 element, the global {{$myGlobal}} which is in itself a list. In other words and pseudocode it's checking if: {code:java} "anton" ? { ["anton", "giertli"] } {code} which is false. Please notice the set on the right (marked by the { } parenthesis) contains 1 element, the list represented by the [ ] parenthesis ---- This can be demonstrated also by changing the test for message to contain an arbitrary Object, as: !screenshot-1.png|thumbnail! which would realize the check {code:java} ["anton", "giertli"] ? { ["anton", "giertli"] } {code} which is then true, and making {{testInOperator()}} pass. ---- Please notice only the *_first_* rule in the description is doing semantically what I expect is actually desired by the reporter which is: {code:java} "anton" ? { "anton", "giertli" } {code} (you can notice now the set on the right marked by the { } parenthesis contains 2 elements) > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip, screenshot-1.png > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 08:00:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 3 Mar 2017 08:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-1461. --------------------------------- Resolution: Rejected > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip, screenshot-1.png > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 08:24:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 08:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated ELY-988: ----------------------------- Affects Version/s: 1.1.0.Beta28 > Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly > --------------------------------------------------------------------------------------- > > Key: ELY-988 > URL: https://issues.jboss.org/browse/ELY-988 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. > In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: > * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created > * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created > Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 08:24:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 08:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly In-Reply-To: References: Message-ID: Ondrej Lukas created ELY-988: -------------------------------- Summary: Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly Key: ELY-988 URL: https://issues.jboss.org/browse/ELY-988 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 08:31:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 3 Mar 2017 08:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-989) Create tests for AuthenticationContext In-Reply-To: References: Message-ID: Ondrej Lukas created ELY-989: -------------------------------- Summary: Create tests for AuthenticationContext Key: ELY-989 URL: https://issues.jboss.org/browse/ELY-989 Project: WildFly Elytron Issue Type: Bug Components: Testsuite Affects Versions: 1.1.0.Beta28 Reporter: Ondrej Lukas Assignee: Ondrej Lukas -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 08:53:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Fri, 3 Mar 2017 08:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8202) CS tool, format Missing required option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372286#comment-13372286 ] Ilia Vassilev commented on WFLY-8202: ------------------------------------- [~mchoma] The message is formatted by Apache cli lib and it is standard for such tools (see [1]). [1] http://grepcode.com/file/repo1.maven.org/maven2/commons-cli/commons-cli/1.3.1/org/apache/commons/cli/MissingOptionException.java#MissingOptionException.createMessage%28java.util.List%29 > CS tool, format Missing required option > --------------------------------------- > > Key: WFLY-8202 > URL: https://issues.jboss.org/browse/WFLY-8202 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma at localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 08:57:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Fri, 3 Mar 2017 08:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: Martin Choma created WFLY-8286: ---------------------------------- Summary: Elytron, log cause of LoginException during obraining ticket Key: WFLY-8286 URL: https://issues.jboss.org/browse/WFLY-8286 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. In log there is {code:title=server.log} 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. {code} But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. Mesage {code:java|title=ElytronMessages} @Message(id = 1121, value = "Unable to perform initial JAAS login.") GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); {code} is created in {code:java|title=GSSCredentialSecurityFactory.java#L283} } catch (LoginException e) { throw log.unableToPerformInitialLogin(e); } {code} and logged into log by {code:java|title=ServerAuthenticationContext.java#L847} } catch (GeneralSecurityException e) { // skip this credential log.trace(e); } {code} An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:07:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Fri, 3 Mar 2017 09:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8202) CS tool, format Missing required option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372307#comment-13372307 ] Martin Choma commented on WFLY-8202: ------------------------------------ If it is not possible to tweak library behavior, then keep as is. > CS tool, format Missing required option > --------------------------------------- > > Key: WFLY-8202 > URL: https://issues.jboss.org/browse/WFLY-8202 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma at localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:11:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 09:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372312#comment-13372312 ] David Lloyd commented on WFLY-8286: ----------------------------------- I think the solution to this should be that we accumulate encountered Throwables; then if we throw an exception in the end, we can attach them as suppressed. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:12:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 09:12:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372313#comment-13372313 ] David Lloyd commented on WFLY-8286: ----------------------------------- In this case though the code does not look right. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:16:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 09:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372316#comment-13372316 ] David Lloyd commented on WFLY-8286: ----------------------------------- In commit 8653945673c5712ce533db1cd21db8ee6a2b6e59 we switched from multiple server credentials to a single credential. This, and also using SecurityFactory for this, might be an error: we should probably convert this to CredentialSource so it works the same way that client auth does. [~dlofthouse] WDYT? I also think that absorbing the GSE is probably wrong in this case. It should be propagated to cause an auth failure. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:19:01 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 09:19:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372317#comment-13372317 ] David Lloyd commented on WFLY-8286: ----------------------------------- Going to expand on this a little. If there is no credential which matches the parameters in the callback, that's fine: the callback is still supported and we should return without setting the credential. Then the mech might know to try another option. If there *is* a matching credential, then if acquiring the credential fails, it's probably going to be a fatal auth problem. If it turns out I'm wrong, we can still move to the accumulate/addSuppressed strategy I described before. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:22:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 09:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned WFLY-8286: --------------------------------- Assignee: David Lloyd (was: Darran Lofthouse) > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: David Lloyd > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:39:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 3 Mar 2017 09:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-8160: ------------------------------ Priority: Major (was: Blocker) > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 09:40:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 3 Mar 2017 09:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-56) Middleware Manager: Rolling upgrades (on Kubernetes) In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-56: ---------------------------------------- Summary: Middleware Manager: Rolling upgrades (on Kubernetes) Key: HAWKULARQE-56 URL: https://issues.jboss.org/browse/HAWKULARQE-56 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: mfoley user Information from Heiko: This may be less of a need to Hawkular-Metrics in OS-Enterprise where people do some install from scratch, but I guess with the OS-Online 1st effort, we will deliver more releases in a quicker cadence, where the chance of such a rollback increases. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:01:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 10:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8287) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: David Lloyd created WFLY-8287: --------------------------------- Summary: Elytron, log cause of LoginException during obraining ticket Key: WFLY-8287 URL: https://issues.jboss.org/browse/WFLY-8287 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: David Lloyd Priority: Critical I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. In log there is {code:title=server.log} 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. {code} But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. Mesage {code:java|title=ElytronMessages} @Message(id = 1121, value = "Unable to perform initial JAAS login.") GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); {code} is created in {code:java|title=GSSCredentialSecurityFactory.java#L283} } catch (LoginException e) { throw log.unableToPerformInitialLogin(e); } {code} and logged into log by {code:java|title=ServerAuthenticationContext.java#L847} } catch (GeneralSecurityException e) { // skip this credential log.trace(e); } {code} An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:01:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 10:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-990) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd moved WFLY-8287 to ELY-990: --------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-990 (was: WFLY-8287) Component/s: Authentication Server (was: Security) > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: ELY-990 > URL: https://issues.jboss.org/browse/ELY-990 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Server > Reporter: Martin Choma > Assignee: David Lloyd > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:04:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 10:04:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6144) Global EJB Client Side Interceptors Configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372373#comment-13372373 ] David Lloyd commented on WFLY-6144: ----------------------------------- All the jboss-ejb-client scaffolding is present now. Just needs management model changes to add the interceptors. > Global EJB Client Side Interceptors Configuration > ------------------------------------------------- > > Key: WFLY-6144 > URL: https://issues.jboss.org/browse/WFLY-6144 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Brad Maxwell > Assignee: David Lloyd > > Ability to configure global client side JBoss EJB interceptors and specify their order via the JBoss profile xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 10:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2359) Failure message when an op requires a non-existent capability doesn't list registration points for dynamic caps In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2359: ---------------------------------------- Summary: Failure message when an op requires a non-existent capability doesn't list registration points for dynamic caps Key: WFCORE-2359 URL: https://issues.jboss.org/browse/WFCORE-2359 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry {code} [standalone at embedded /] /socket-binding-group=standard-sockets/socket-binding=test:add(interface=bogus,port=12345) { "outcome" => "failed", "failure-description" => "WFLYCTL0369: Required capabilities are not available: org.wildfly.network.interface.bogus; There are no known registration points which can provide this capability.", "rolled-back" => true } {code} The failure message is not fully helpful, since while there are no reg points for org.wildfly.network.interface.bogus there are points for caps whose dynamic part is org.wildfly.network.interface. The message is created using the results of CapabilityRegistry.getPossibleProviderPoints(), which just does a map lookup of the passed in capability name. Any fix that changes getPossibleProviderPoints() will need to be careful not to break other uses of that method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:38:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 3 Mar 2017 10:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8288) Drop ASYNC cache mode, in favor of manual async operations and async commit/rollback In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-8288: ---------------------------------- Summary: Drop ASYNC cache mode, in favor of manual async operations and async commit/rollback Key: WFLY-8288 URL: https://issues.jboss.org/browse/WFLY-8288 Project: WildFly Issue Type: Enhancement Components: Clustering Reporter: Paul Ferraro Assignee: Paul Ferraro Infinispan is moving away from ASYNC mode, in favor of the async cache API. This is a good thing, as it clarifies cache operation semantics and eliminates the abuse of invocation flags. ASYNC vs SYNC behavior should move to the new subsystems for configuring web and ejb clustering profiles. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:48:01 2017 From: issues at jboss.org (Radovan Netuka (JIRA)) Date: Fri, 3 Mar 2017 10:48:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radovan Netuka reassigned SECURITY-921: --------------------------------------- Assignee: Radovan Netuka (was: Darran Lofthouse) > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1 > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:50:01 2017 From: issues at jboss.org (Radovan Netuka (JIRA)) Date: Fri, 3 Mar 2017 10:50:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372428#comment-13372428 ] Radovan Netuka commented on SECURITY-921: ----------------------------------------- PR for 2.3.x: https://github.com/wildfly-security/jboss-negotiation/pull/35 > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 10:50:00 2017 From: issues at jboss.org (Radovan Netuka (JIRA)) Date: Fri, 3 Mar 2017 10:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radovan Netuka updated SECURITY-921: ------------------------------------ Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/35 Affects Version/s: Negotiation_2_3_11_Final > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 11:13:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 3 Mar 2017 11:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1356) Advance PseudoClock in KIE-Server/Decision Server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-1356: ----------------------------------- Assignee: Mario Fusco (was: Matteo Mortari) > Advance PseudoClock in KIE-Server/Decision Server > ------------------------------------------------- > > Key: DROOLS-1356 > URL: https://issues.jboss.org/browse/DROOLS-1356 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 7.0.0.Beta2 > Environment: JBoss BRMS 6.4.0, macOS 10.11.1, Oracle Hotspot 1.8.0_101 > Reporter: Duncan Doyle > Assignee: Mario Fusco > > KIE-Server does not provide a command to advance the time of a pseudo-clock. This functionality is required (or at least, highly useful) when KIE-Server is used for CEP sessions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 11:22:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 11:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9300 to WFCORE-2360: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2360 (was: JBEAP-9300) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) (was: User Experience) Affects Version/s: 3.0.0.Beta6 (was: 7.1.0.DR13) > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta6 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain at localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain at localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 11:22:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 11:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2360: ------------------------------------- Affects Version/s: (was: 3.0.0.Beta6) > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain at localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain at localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 11:30:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Fri, 3 Mar 2017 11:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-57) Use hawkular/hawkular-services images for LOTE In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-57: ------------------------------------- Summary: Use hawkular/hawkular-services images for LOTE Key: HAWKULARQE-57 URL: https://issues.jboss.org/browse/HAWKULARQE-57 Project: Hawkular QE Issue Type: Task Reporter: viet nguyen Assignee: mfoley user Priority: Minor Development has introduced a OpenShift pod for hawkular services. We should run livingontheedge.hawkular.org with this instead of our own https://github.com/Hawkular-QE/hawkular-services-docker -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 11:32:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Fri, 3 Mar 2017 11:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1356) Advance PseudoClock in KIE-Server/Decision Server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372469#comment-13372469 ] Matteo Mortari commented on DROOLS-1356: ---------------------------------------- I suggest to have actually two commands for advance. The first one shall reflect existing API, this is a draft: https://github.com/tarilabs/drools/blob/patch-pseudoclockcmds/drools-core/src/main/java/org/drools/core/command/runtime/PseudoClockAdvanceTimeCommand.java The second one shall "compare and change" similar to java AtomicNumber as this command might be helpful given a kie-server is a remote CEP, this is a draft: https://github.com/tarilabs/drools/blob/patch-pseudoclockcmds/drools-core/src/main/java/org/drools/core/command/runtime/PseudoClockCompareAndSetCommand.java I have a concern as the {{`GetSessionClockCommand`}} was also existing at the time I drafted the commands above^, yet I carried on trying to roll my own to just get the value out: https://github.com/tarilabs/drools/blob/patch-pseudoclockcmds/drools-core/src/main/java/org/drools/core/command/runtime/SessionClockGetCurrentTimeCommand.java I'm not sure why. > Advance PseudoClock in KIE-Server/Decision Server > ------------------------------------------------- > > Key: DROOLS-1356 > URL: https://issues.jboss.org/browse/DROOLS-1356 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 7.0.0.Beta2 > Environment: JBoss BRMS 6.4.0, macOS 10.11.1, Oracle Hotspot 1.8.0_101 > Reporter: Duncan Doyle > Assignee: Mario Fusco > > KIE-Server does not provide a command to advance the time of a pseudo-clock. This functionality is required (or at least, highly useful) when KIE-Server is used for CEP sessions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 12:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 12:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372504#comment-13372504 ] Brian Stansberry commented on WFCORE-2348: ------------------------------------------ There is no downstream dependency here. These files are not used in EAP. There is no docs/contrib folder in the EAP distribution. > Error while starting WildFly as service in domain mode using init scripts. > -------------------------------------------------------------------------- > > Key: WFCORE-2348 > URL: https://issues.jboss.org/browse/WFCORE-2348 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta7 > Environment: Fedora, RHEL > Reporter: Radovan Stancel > Assignee: Radovan Stancel > Priority: Minor > Labels: downstream_dependency > Original Estimate: 4 hours > Time Spent: 3 hours > Remaining Estimate: 1 hour > > When starting WildFly as a service in domain mode using init scripts there appears in console.log error: > /usr/bin/dirname: unrecognized option '--domain-config=domain.xml' > Try '/usr/bin/dirname --help' for more information. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 13:08:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 3 Mar 2017 13:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8262) Upgrade to jboss-el-api 1.0.9.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-8262: ------------------------------ Summary: Upgrade to jboss-el-api 1.0.9.Final (was: Upgrade to jboss-el-api 1.0.8.Final) > Upgrade to jboss-el-api 1.0.9.Final > ----------------------------------- > > Key: WFLY-8262 > URL: https://issues.jboss.org/browse/WFLY-8262 > Project: WildFly > Issue Type: Task > Components: Build System, EE > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Upgrade to 1.0.8. To include JBEE-174 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 13:08:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 3 Mar 2017 13:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8262) Upgrade to jboss-el-api 1.0.9.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-8262: ------------------------------ Description: Upgrade to 1.0.9. To include JBEE-174 (was: Upgrade to 1.0.8. To include JBEE-174) > Upgrade to jboss-el-api 1.0.9.Final > ----------------------------------- > > Key: WFLY-8262 > URL: https://issues.jboss.org/browse/WFLY-8262 > Project: WildFly > Issue Type: Task > Components: Build System, EE > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Upgrade to 1.0.9. To include JBEE-174 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 13:09:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 3 Mar 2017 13:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2077) OutOfMemoryError: Metaspace after several client calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFCORE-2077. --------------------------------- Fix Version/s: 3.0.0.Beta5 Resolution: Done I think it is safe to resolve this now. If noting else, initial problems ware addressed. If new ones are found, new jira should be opened. > OutOfMemoryError: Metaspace after several client calls > ------------------------------------------------------ > > Key: WFCORE-2077 > URL: https://issues.jboss.org/browse/WFCORE-2077 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha13 > Reporter: Petr Kremensky > Assignee: Tomaz Cerar > Priority: Blocker > Fix For: 3.0.0.Beta5 > > > I saw some java.lang.OutOfMemoryError: Metaspace in our AS-Testsuite runs. Here is a really simple (and clumsy) reproducer for the leak. > *repreduce* > {noformat} > # lower the metaspace size in jboss-eap-7.1/bin/standalone.conf to > # -XX:MaxMetaspaceSize=64m > # start standalone > ./jboss-eap-7.1/bin/standalone.sh > # run the following loop (any other mgmt operation should serve the same) > for i in `seq 1 1000` ; do ./jboss-eap-7.1/bin/jboss-cli.sh -c :read-resource ; done > # wait for OOM > {noformat} > {noformat} > 14:24:29,629 WARN [org.jboss.modules] (MSC service thread 1-3) Failed to define class io.undertow.security.impl.SimpleNonceManager in Module "io.undertow.core:main" from local module loader @629f0666 (finder: local module finder @1bc6a36e (roots: /home/pkremens/workspace/jboss-eap-7.1/modules,/home/pkremens/workspace/jboss-eap-7.1/modules/system/layers/base)): java.lang.OutOfMemoryError: Metaspace > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:763) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:359) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:438) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:612) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94) > at org.jboss.as.domain.http.server.security.LogoutHandler.(LogoutHandler.java:76) > at org.jboss.as.domain.http.server.ManagementHttpServer.addLogoutHandler(ManagementHttpServer.java:316) > at org.jboss.as.domain.http.server.ManagementHttpServer.setupOpenListener(ManagementHttpServer.java:395) > at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:271) > at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107) > at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589) > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 13:42:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Fri, 3 Mar 2017 13:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1462) not( null ) unary test not working In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1462: ------------------------------------- Summary: not( null ) unary test not working Key: DROOLS-1462 URL: https://issues.jboss.org/browse/DROOLS-1462 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta6 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final The engine is not properly creating the unary test ```not( null )``` and raising a NPE. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 13:51:00 2017 From: issues at jboss.org (Yeray Borges Santana (JIRA)) Date: Fri, 3 Mar 2017 13:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8234) RemoteAsyncInvocationTestCase fails with Elytron profile in AS TS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372536#comment-13372536 ] Yeray Borges Santana commented on WFLY-8234: -------------------------------------------- I cannot reproduce it with current wildfly master branch {code} ------------------------------------------------------ T E S T S ------------------------------------------------------- Running org.jboss.as.test.integration.ejb.remote.async.RemoteAsyncInvocationTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.375 sec - in org.jboss.as.test.integration.ejb.remote.async.RemoteAsyncInvocationTestCase Results : Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 27.568 s [INFO] Finished at: 2017-03-03T18:43:35+00:00 [INFO] Final Memory: 113M/656M [INFO] ------------------------------------------------------------------------ Java version: 1.8.0_121, vendor: Oracle Corporation OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" git rev-parse HEAD 1c270e9bcf3bcb7e4b711c8bc7a4f627ccfb7fe0 {code} > RemoteAsyncInvocationTestCase fails with Elytron profile in AS TS > ----------------------------------------------------------------- > > Key: WFLY-8234 > URL: https://issues.jboss.org/browse/WFLY-8234 > Project: WildFly > Issue Type: Bug > Components: EJB, Test Suite > Reporter: Josef Cacek > > The {{RemoteAsyncInvocationTestCase.testLocalAsyncInvocationByValue}} test fails on {{NullPointerException}} when executed with Elytron profile in AS TS. > {code} > cd testsuite/integration/basic > mvn clean test -Dtest=RemoteAsyncInvocationTestCase -Delytron > ... > Tests in error: > RemoteAsyncInvocationTestCase.testLocalAsyncInvocationByValue:97 ? NullPointer > Tests run: 4, Failures: 0, Errors: 1, Skipped: 0 > {code} > Full stack trace. > {code} > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > 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.lang.NullPointerException > at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1.processInvocation(AsyncFutureInterceptorFactory.java:85) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextStorageInterceptor.processInvocation(LogDiagnosticContextStorageInterceptor.java:71) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) > at org.jboss.as.test.integration.ejb.remote.async.LocalInterface$$$view2.passByReference(Unknown Source) > at org.jboss.as.test.integration.ejb.remote.async.RemoteAsyncInvocationTestCase.testLocalAsyncInvocationByValue(RemoteAsyncInvocationTestCase.java:97) > ... 144 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 13:59:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Fri, 3 Mar 2017 13:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2453) Expose statistics configuration attribute per JGroups protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar reassigned WFLY-2453: ------------------------------------ Assignee: Radoslav Husar (was: Paul Ferraro) > Expose statistics configuration attribute per JGroups protocol > -------------------------------------------------------------- > > Key: WFLY-2453 > URL: https://issues.jboss.org/browse/WFLY-2453 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > By default, every JGroups protocol gathers statistics. Currently, this can be disabled per protocol via: > false > This is a bit cumbersome. Also, a standard property like this should be 1st class attribute of the element. > e.g.. > > We may also want to add the ability to disable statistics per stack, so the user does not have to explicitly disable it in every protocol. That way, to enable statistics for a single protocol, one could use: > > > ... > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 14:43:00 2017 From: issues at jboss.org (Peter Nalyvayko (JIRA)) Date: Fri, 3 Mar 2017 14:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1705) A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372556#comment-13372556 ] Peter Nalyvayko commented on WFCORE-1705: ----------------------------------------- Seems that some of the classes in that namespace are not portable across different JVMs, so decided to implement the missing functionality (OCSP checking) instead of relying on types from provider/certpath. Since this isn't an issue any longer, I feel I should close the issue. > A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1705 > URL: https://issues.jboss.org/browse/WFCORE-1705 > Project: WildFly Core > Issue Type: Bug > Components: Modules, Server > Affects Versions: 2.2.0.Final > Reporter: Peter Nalyvayko > Assignee: David Lloyd > Labels: jboss > > There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there: > {{ > > > > > > > > > ... > > > > > > > > > > ... > > > > > > > > > > }}Manually adding the missing system dependency path fixes the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 14:43:00 2017 From: issues at jboss.org (Peter Nalyvayko (JIRA)) Date: Fri, 3 Mar 2017 14:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1705) A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Nalyvayko closed WFCORE-1705. ----------------------------------- Resolution: Won't Do > A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1705 > URL: https://issues.jboss.org/browse/WFCORE-1705 > Project: WildFly Core > Issue Type: Bug > Components: Modules, Server > Affects Versions: 2.2.0.Final > Reporter: Peter Nalyvayko > Assignee: David Lloyd > Labels: jboss > > There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there: > {{ > > > > > > > > > ... > > > > > > > > > > ... > > > > > > > > > > }}Manually adding the missing system dependency path fixes the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 14:50:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 14:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-991) SASL Digest client handles callbacks incorrectly In-Reply-To: References: Message-ID: David Lloyd created ELY-991: ------------------------------- Summary: SASL Digest client handles callbacks incorrectly Key: ELY-991 URL: https://issues.jboss.org/browse/ELY-991 Project: WildFly Elytron Issue Type: Bug Components: Authentication Mechanisms, SASL Reporter: David Lloyd Right now the SASL digest client handles callbacks like this: * If a realm choice is available use RealmChoiceCallback to get it, and fail if it is not supported * Try to use RealmCallback+NameCallback+CredentialCallback (with digest password) * Try to use RealmCallback+NameCallback+CredentialCallback (with two-way password) * Try to use RealmCallback+NameCallback+PasswordCallback This is a problem because RealmChoiceCallback should not be required, and if it was supported, RealmCallback is not needed. It's basically OK to retry realm selection and name selection if the credential was unsupported. The logic should probably be more like this: * Try to use +NameCallback+CredentialCallback (with digest password) ** First try with RealmChoiceCallback if there is a choice ** Then try with RealmCallback if RealmChoiceCallback is unsupported ** If there is no default realm, fail ** Otherwise try with no realm callback and use the default realm * Try to use +NameCallback+CredentialCallback (with two-way password) ** First try with RealmChoiceCallback if it was not eliminated above and there is a choice ** Then try RealmCallback if it was not eliminated above ** If there is no default realm, fail ** Otherwise try with no realm callback and use the default realm * Try to use +NameCallback+PasswordCallback ** First try with RealmChoiceCallback if it was not eliminated above and there is a choice ** Then try RealmCallback if it was not eliminated above ** If there is no default realm, fail ** Otherwise try with no realm callback and use the default realm This way we don't retry callbacks that don't work, and we don't fail if RealmCallback is not supported. If no user name or credential is given, then the attempt should be considered a failure and the next credential tried without eliminating any realm callbacks. If no realm is given then the attempt should be a failure without trying other realm callback options, because the callback is supported but there was no realm given (which is a programming error). If a user name or realm is given in an earlier stage, it should stay as the default for later stages. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 15:06:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 3 Mar 2017 15:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-987) Confusion in method with(AuthenticationContext other) in AuthenticationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned ELY-987: ------------------------------- Assignee: David Lloyd (was: Darran Lofthouse) > Confusion in method with(AuthenticationContext other) in AuthenticationContext > ------------------------------------------------------------------------------ > > Key: ELY-987 > URL: https://issues.jboss.org/browse/ELY-987 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: David Lloyd > Priority: Critical > > org.wildfly.security.auth.client.AuthenticationContext includes method {{AuthenticationContext with(AuthenticationContext other)}} which creates new AuthenticationContext which includes rules and configuration and SSL context of given AuthenticationContext other. > However, in case when {{with}} method is used with index and another AuthenticationContext, then it includes only rules and configuration (SSL context is not used). There is also method {{withSsl}} which includes rules and SSL context, but no configuration. > I see three problems here: > * there is different behavior between {{with(AuthenticationContext other)}} and {{with(int idx, AuthenticationContext other)}} - first includes also SSL context > * javadoc for with(AuthenticationContext other) does not describe that SSL context from given {{AuthenticationContext other}} is also used. > * there is not able to include both configuration and SSL context into any AuthenticationContext on some position based on index > I report this as critical because it is part of public API - it should stay backward compatible once it will be released. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 15:18:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 15:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7063) IdentityLoginModuleTestCase is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-7063: ----------------------------------- Fix Version/s: 10.2.0.Final > IdentityLoginModuleTestCase is incorrect > ---------------------------------------- > > Key: WFLY-7063 > URL: https://issues.jboss.org/browse/WFLY-7063 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 10.2.0.Final, 11.0.0.Alpha1 > > > This test assumes that the security path of '/' will be a wildcard match, while in reality it should only match the root url. This test only passed due to UNDERTOW-805 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 15:23:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 15:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372579#comment-13372579 ] Brian Stansberry commented on WFCORE-1958: ------------------------------------------ PR #2218 is merged so no tests are ignored with reference to this now. > Clean up testsuite Elytron registration > --------------------------------------- > > Key: WFCORE-1958 > URL: https://issues.jboss.org/browse/WFCORE-1958 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta7 > > > In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them.. > Also re-enable the following test case: - > * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 16:06:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 16:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7539) WebSocketTestCase fails with security manager - disable test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-7539: ----------------------------------- Fix Version/s: 10.2.0.Final > WebSocketTestCase fails with security manager - disable test > ------------------------------------------------------------ > > Key: WFLY-7539 > URL: https://issues.jboss.org/browse/WFLY-7539 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Fix For: 10.2.0.Final, 11.0.0.Alpha1 > > > With the core 3.0.0.Alpha12 upgrade we see failures in the WebSocketTestCase when run with the security manager enabled. > $mvn clean install -pl testsuite/integration/web/ -Dsecurity.manager=true > For now I am adding a > {code} > Assume.assumeTrue(System.getSecurityManager() == null); > {code} > to skip this test when running with a security manager enabled. The failure when the test is run with a security manager is > {code} > testWebSocket(org.jboss.as.test.integration.web.websocket.WebSocketTestCase)??Time elapsed: 0.227 sec??<<< ERROR! > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:0" "listen,resolve")" in code source "(vfs:/content/websocket.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.websocket.war:main" 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.SecurityManager.checkListen(SecurityManager.java:1131) > ??at org.wildfly.security.manager.WildFlySecurityManager.checkListen(WildFlySecurityManager.java:392) > ??at sun.nio.ch.SocketChannelImpl.bind(SocketChannelImpl.java:582) > ??at sun.nio.ch.SocketAdaptor.bind(SocketAdaptor.java:135) > ??at org.xnio.nio.WorkerThread.openTcpStreamConnection(WorkerThread.java:263) > ??at org.xnio.XnioIoThread.openStreamConnection(XnioIoThread.java:237) > ??at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:342) > ??at org.xnio.http.HttpUpgrade$HttpUpgradeState.doUpgrade(HttpUpgrade.java:247) > ??at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$100(HttpUpgrade.java:165) > ??at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:129) > ??at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connectImpl(WebSocketClient.java:323) > ??at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connect(WebSocketClient.java:211) > ??at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:463) > ??at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:457) > ??at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServer(ServerWebSocketContainer.java:211) > ??at org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testWebSocket(WebSocketTestCase.java:52) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 16:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 16:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1507) Expose features currently provided by ModelController via capabilities usable by extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1507: ------------------------------------- Summary: Expose features currently provided by ModelController via capabilities usable by extensions (was: Expose the ModelController via a capability) > Expose features currently provided by ModelController via capabilities usable by extensions > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1507 > URL: https://issues.jboss.org/browse/WFCORE-1507 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > A server installs ServerService while an HC installs DomainModelControllerService, under different service names but both of which implement Service. To make it easier for subsystems that want ModelController access to work on both a server and an HC, we should create a capability with service type ModelController and have both processes use it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 16:51:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 16:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2350) In legacy security realms grant RemoteEJBPermission and RemoteTransactionPermission by default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372597#comment-13372597 ] Brian Stansberry commented on WFCORE-2350: ------------------------------------------ [~dlofthouse] This wasn't listed in your comment for https://github.com/wildfly/wildfly-core/pull/2222 but I think it should be resolved based on that PR. > In legacy security realms grant RemoteEJBPermission and RemoteTransactionPermission by default. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2350 > URL: https://issues.jboss.org/browse/WFCORE-2350 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta7 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:09:00 2017 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Fri, 3 Mar 2017 17:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8237) Upgrade to xalan 2.7.1.jbossorg-4 and include fix for cve-2014-0107 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Marlow closed WFLY-8237. ------------------------------ > Upgrade to xalan 2.7.1.jbossorg-4 and include fix for cve-2014-0107 > ------------------------------------------------------------------- > > Key: WFLY-8237 > URL: https://issues.jboss.org/browse/WFLY-8237 > Project: WildFly > Issue Type: Task > Components: XML Frameworks > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > EAP is still using 2.7.1 with our patches on top of it. > It would be wise to upgrade to 2.7.2 and add any missing patches we did to 2.7.1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2350) In legacy security realms grant RemoteEJBPermission and RemoteTransactionPermission by default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2350: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > In legacy security realms grant RemoteEJBPermission and RemoteTransactionPermission by default. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2350 > URL: https://issues.jboss.org/browse/WFCORE-2350 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2349: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. > --------------------------------------------------------------------------------- > > Key: WFCORE-2349 > URL: https://issues.jboss.org/browse/WFCORE-2349 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not validated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2317: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Nested attributes are not validated > ----------------------------------- > > Key: WFCORE-2317 > URL: https://issues.jboss.org/browse/WFCORE-2317 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha25 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 3.0.0.Beta8 > > > Attributes of type Object do not have their inner attributes validated for e.g. "requires" and "alternatives". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2302) Ensure sensitivity CREDENTIAL is only applied to clear-password, add CredentialRef for the referencing attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2302: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Ensure sensitivity CREDENTIAL is only applied to clear-password, add CredentialRef for the referencing attribute. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2302 > URL: https://issues.jboss.org/browse/WFCORE-2302 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2352) Migrate the WildFly Elytron subsystem to WildFly Core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2352: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Migrate the WildFly Elytron subsystem to WildFly Core > ----------------------------------------------------- > > Key: WFCORE-2352 > URL: https://issues.jboss.org/browse/WFCORE-2352 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta8 > > > This task is to move the subsystem to WildFly Core. This task is not to add the subsystem to any additional feature packs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852] In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2301: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852] > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-2301 > URL: https://issues.jboss.org/browse/WFCORE-2301 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: WildFly via KeyCloak 2.5.1.Final > {code:xml} > 7.0.0.Beta > 7.2.0.Final > 10.0.0.Final > {code} > on Docker with overlayfs or overlayfs2 as storage driver > \# docker info | grep -i storage > aufs: works (e.g., boot2docker, legacy minikube) > overlay (e.g., CoreOS, current minikube): problem > devicemapper (e.g., CentOS): works > overlay2 (e.g., Docker for Mac): problem > Reporter: Bjoern Stuetz > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta8, 2.2.1.CR2 > > > Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e., > /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli > inside a Docker container running on overlayfs as storage driver > causes (full stack trace below): > {code:java} > java.io.IOException: Mount point not foundImage > at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91) > {code} > triggered by > {code:java} > at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117) > at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104) > {code} > due to OpenJDK bug/overlayfs bug. > We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on the Java or WildFly side; but we might need insights on why findMountEntry is invoked. > Full Stack Trace: > {code:java} > java.io.IOException: Mount point not foundImage > at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91) > at sun.nio.fs.UnixFileStore.(UnixFileStore.java:65) > at sun.nio.fs.LinuxFileStore.(LinuxFileStore.java:44) > at sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:51) > at sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:39) > at sun.nio.fs.UnixFileSystemProvider.getFileStore(UnixFileSystemProvider.java:368) > at java.nio.file.Files.getFileStore(Files.java:1461) > at org.jboss.as.controller.persistence.FilePersistenceUtils.getPosixAttributes(FilePersistenceUtils.java:129) > at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117) > at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104) > at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55) > at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58) > at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649) > at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63) > at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59) > at org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle(BatchRunHandler.java:91) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776) > at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799) > at org.jboss.as.cli.impl.CliLauncher.processFile(CliLauncher.java:334) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.modules.Module.run(Module.java:329) > at org.jboss.modules.Main.main(Main.java:507) > {code} > Java Bug Overview: > https://bugs.openjdk.java.net/browse/JDK-8165852 > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/nio/fs/LinuxFileStore.java#91 > Wildfly Stack Overflow issue, not solved: > https://stackoverflow.com/questions/41022393/mount-point-not-found > Background Info: > http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html > A) chroot environment [1] > B) Docker container with overlay and overlay2 storage drivers [2] > C) btrfs file system with an unmounted sub-volume [2] > [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment > [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker > Docker file system/storage driver: > https://docs.docker.com/engine/userguide/storagedriver/selectadriver/) > Yum yum-plugin-ovl, similar problem: > https://github.com/CentOS/sig-cloud-instance-images/issues/15 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2267: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2267 > URL: https://issues.jboss.org/browse/WFCORE-2267 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > Only the Elytron realms are now used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2245: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > credential-reference capability-reference constraint > ---------------------------------------------------- > > Key: WFCORE-2245 > URL: https://issues.jboss.org/browse/WFCORE-2245 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Claudio Miranda > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > There attribute credential-reference is defined in many subsystems as below. Looks like the capability-reference constraint should be set in the "store" field of the value-type, therefore I request a review on this capability-constraint placement. > {code} > "credential-reference" => { > "type" => OBJECT, > "description" => "Credential (from Credential Store) to authenticate on data source", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.credential-store", > "access-constraints" => {"sensitive" => { > "credential" => {"type" => "core"}, > "data-source-security" => {"type" => "datasources"} > }}, > "value-type" => { > "store" => { > "type" => STRING, > "description" => "The name of the credential store holding the alias to credential", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "alias" => { > "type" => STRING, > "description" => "The alias which denotes stored secret or credential in the store", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "type" => { > "type" => STRING, > "description" => "The type of credential this reference is denoting", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "clear-text" => { > "type" => STRING, > "description" => "Secret specified using clear text (check credential store way of supplying credential/secrets to services)", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron 1.1.0.Beta20 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2206: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Upgrade to WildFly Elytron 1.1.0.Beta20 > --------------------------------------- > > Key: WFCORE-2206 > URL: https://issues.jboss.org/browse/WFCORE-2206 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2163: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-2163 > URL: https://issues.jboss.org/browse/WFCORE-2163 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta8 > > > In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started. > I am using following configuration for HTTP management interface (see Steps to Reproduce for more details): > {code} > > > > > {code} > Server is not started and following errors occur in log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > 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.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided. > at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225) > at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254) > at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107) > at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589) > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292) > ... 5 more > {code} > and > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {code} > According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication. > [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJiSEGwI/edit# -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2136: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:07 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2101) Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2101: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2101 > URL: https://issues.jboss.org/browse/WFCORE-2101 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > i.e. a later AS release will start to enable mechs like SCRAM, client should work without additional configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:07 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2100: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:07 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown roles instead of throwing exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2071: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Properly handle unknown roles instead of throwing exception > ----------------------------------------------------------- > > Key: WFCORE-2071 > URL: https://issues.jboss.org/browse/WFCORE-2071 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Pedro Igor > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > When mapping roles directly from the identity: > {code} > > {code} > If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. > Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:07 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2068: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2068 > URL: https://issues.jboss.org/browse/WFCORE-2068 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The listed test case is failing during clean up with the following error: - > {noformat} > java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80) > {noformat} > The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:08 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2046: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > KeyManager synchronization issue when using IBM JDK > --------------------------------------------------- > > Key: WFCORE-2046 > URL: https://issues.jboss.org/browse/WFCORE-2046 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > Attachments: test-app-ibm-jdk-keymanager-sync.zip > > > We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords. > As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines. > Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}). > The workflow: > # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}} > # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}} > # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore. > *Possible workaround* > We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:08 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2016: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Change sasl-authentication-factor for management auth works after reload, but not after server restart > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2016 > URL: https://issues.jboss.org/browse/WFCORE-2016 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > I can successfully configure a new sasl-authentication-factory and assign it to the management interface: > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"]) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper) > /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) > reload > {code} > after reload, i am forced to re-authenticate and it succeeds: > {code} > [standalone at localhost:9990 /] reload > Authenticating against security realm: exampleSaslRealm > Username: user1 > Password: > [standalone at localhost:9990 /] > {code} > Once i restart the server though and try to connect, i get a timeout: > {code} > $ ./jboss-cli.sh -c > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code} > It also fails if i force no local auth: > {code} > $ ./jboss-cli.sh -c --no-local-auth > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code}/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:08 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the jboss-logging-annotations dependency from the core feature pack. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1965: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Remove the jboss-logging-annotations dependency from the core feature pack. > --------------------------------------------------------------------------- > > Key: WFCORE-1965 > URL: https://issues.jboss.org/browse/WFCORE-1965 > Project: WildFly Core > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: James Perkins > Priority: Critical > Fix For: 3.0.0.Beta8 > > > This was added inadvertently with some other changes: - > {noformat} > > org.jboss.logging > jboss-logging-annotations > > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:08 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1960: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta8 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:08 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1958: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Clean up testsuite Elytron registration > --------------------------------------- > > Key: WFCORE-1958 > URL: https://issues.jboss.org/browse/WFCORE-1958 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them.. > Also re-enable the following test case: - > * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:09 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:09 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once migrated to Remoting 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1897: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Follow up WFCORE-296 once migrated to Remoting 5 > ------------------------------------------------ > > Key: WFCORE-1897 > URL: https://issues.jboss.org/browse/WFCORE-1897 > Project: WildFly Core > Issue Type: Task > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:08 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1944: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:09 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:09 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1802: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > We need to remove the following block from SecurityRealmResourceDefinition: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > Registration will then be possible within the Elytron subsystem configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:09 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:09 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1649: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta8 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:10 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:10 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1606: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta8 > > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:10 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:10 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1560: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh > -------------------------------------------------------------------------------- > > Key: WFCORE-1560 > URL: https://issues.jboss.org/browse/WFCORE-1560 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.8.Final > Environment: OS: CentOS 7.2 > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Wildfly-10.0.0-Final > Reporter: Michael Noack > Assignee: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta8 > > Attachments: JVM-DC.png, console-dc.log, host-controller.log, process-controller.log > > > When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am): > [root at dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)" > Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out > I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue. > Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:11 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta8 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:11 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: Ivo Studensky > Priority: Critical > Fix For: 3.0.0.Beta8 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:11 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Beta8 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:11 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-887: ------------------------------------ Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta8 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:11 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta8 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:12 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:12 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta8 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:12 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:12 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-644: ------------------------------------ Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta8 > > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:28:12 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:28:12 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call non-published management API operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Beta8 (was: 3.0.0.Beta7) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Beta8 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:38:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2126) Upgrade to Undertow 1.4.3+ in WFCORE 2.2.1 to resolve CVE-2016-4993 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2126: ---------------------------------------- Fix Version/s: 2.2.1.CR2 Assignee: Frank Langelage Resolution: Done Thanks, Frank! > Upgrade to Undertow 1.4.3+ in WFCORE 2.2.1 to resolve CVE-2016-4993 > ------------------------------------------------------------------- > > Key: WFCORE-2126 > URL: https://issues.jboss.org/browse/WFCORE-2126 > Project: WildFly Core > Issue Type: Component Upgrade > Affects Versions: 2.2.1.CR1 > Reporter: Falko Modler > Assignee: Frank Langelage > Fix For: 2.2.1.CR2 > > > WFCORE-1688 upgraded Undertow to 1.4.0.Final which contains a rather serious sercurity vulnerability which was fixed in Undertow 1.4.3.Final (see UNDERTOW-827). > WildFly Swarm already builds on top of WFCORE 2.2.1.CR1 and will probably switch to 2.2.1.Final once it is released, so from my perspective it would be very sensible to upgrade to a corrected version of Undertow in the next CR (or Final) of WFCORE 2.2.1. > PS: WFCORE seems to build just fine (including tests) when upgrading the Undertow version to 1.4.7.Final in pom.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:43:00 2017 From: issues at jboss.org (Falko Modler (JIRA)) Date: Fri, 3 Mar 2017 17:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2126) Upgrade to Undertow 1.4.3+ in WFCORE 2.2.1 to resolve CVE-2016-4993 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372608#comment-13372608 ] Falko Modler commented on WFCORE-2126: -------------------------------------- Thanks everybody! > Upgrade to Undertow 1.4.3+ in WFCORE 2.2.1 to resolve CVE-2016-4993 > ------------------------------------------------------------------- > > Key: WFCORE-2126 > URL: https://issues.jboss.org/browse/WFCORE-2126 > Project: WildFly Core > Issue Type: Component Upgrade > Affects Versions: 2.2.1.CR1 > Reporter: Falko Modler > Assignee: Frank Langelage > Fix For: 2.2.1.CR2 > > > WFCORE-1688 upgraded Undertow to 1.4.0.Final which contains a rather serious sercurity vulnerability which was fixed in Undertow 1.4.3.Final (see UNDERTOW-827). > WildFly Swarm already builds on top of WFCORE 2.2.1.CR1 and will probably switch to 2.2.1.Final once it is released, so from my perspective it would be very sensible to upgrade to a corrected version of Undertow in the next CR (or Final) of WFCORE 2.2.1. > PS: WFCORE seems to build just fine (including tests) when upgrading the Undertow version to 1.4.7.Final in pom.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 17:57:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 17:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2361) [2.x] Upgrade XNIO to 3.4.3 In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2361: ---------------------------------------- Summary: [2.x] Upgrade XNIO to 3.4.3 Key: WFCORE-2361 URL: https://issues.jboss.org/browse/WFCORE-2361 Project: WildFly Core Issue Type: Component Upgrade Components: IO Reporter: Brian Stansberry Assignee: Frank Langelage Fix For: 2.2.1.CR2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 18:01:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 18:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2361) [2.x] Upgrade XNIO to 3.4.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372611#comment-13372611 ] Brian Stansberry commented on WFCORE-2361: ------------------------------------------ The merge commit for WFCORE-2361 references WFCORE-2116, but in the end it was about 2361. > [2.x] Upgrade XNIO to 3.4.3 > --------------------------- > > Key: WFCORE-2361 > URL: https://issues.jboss.org/browse/WFCORE-2361 > Project: WildFly Core > Issue Type: Component Upgrade > Components: IO > Reporter: Brian Stansberry > Assignee: Frank Langelage > Fix For: 2.2.1.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 18:06:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 3 Mar 2017 18:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852] In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2301: ------------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta8) > Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852] > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-2301 > URL: https://issues.jboss.org/browse/WFCORE-2301 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: WildFly via KeyCloak 2.5.1.Final > {code:xml} > 7.0.0.Beta > 7.2.0.Final > 10.0.0.Final > {code} > on Docker with overlayfs or overlayfs2 as storage driver > \# docker info | grep -i storage > aufs: works (e.g., boot2docker, legacy minikube) > overlay (e.g., CoreOS, current minikube): problem > devicemapper (e.g., CentOS): works > overlay2 (e.g., Docker for Mac): problem > Reporter: Bjoern Stuetz > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta3, 2.2.1.CR2 > > > Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e., > /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli > inside a Docker container running on overlayfs as storage driver > causes (full stack trace below): > {code:java} > java.io.IOException: Mount point not foundImage > at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91) > {code} > triggered by > {code:java} > at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117) > at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104) > {code} > due to OpenJDK bug/overlayfs bug. > We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on the Java or WildFly side; but we might need insights on why findMountEntry is invoked. > Full Stack Trace: > {code:java} > java.io.IOException: Mount point not foundImage > at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91) > at sun.nio.fs.UnixFileStore.(UnixFileStore.java:65) > at sun.nio.fs.LinuxFileStore.(LinuxFileStore.java:44) > at sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:51) > at sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:39) > at sun.nio.fs.UnixFileSystemProvider.getFileStore(UnixFileSystemProvider.java:368) > at java.nio.file.Files.getFileStore(Files.java:1461) > at org.jboss.as.controller.persistence.FilePersistenceUtils.getPosixAttributes(FilePersistenceUtils.java:129) > at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117) > at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104) > at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55) > at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58) > at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659) > at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649) > at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63) > at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59) > at org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle(BatchRunHandler.java:91) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776) > at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799) > at org.jboss.as.cli.impl.CliLauncher.processFile(CliLauncher.java:334) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.modules.Module.run(Module.java:329) > at org.jboss.modules.Main.main(Main.java:507) > {code} > Java Bug Overview: > https://bugs.openjdk.java.net/browse/JDK-8165852 > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/nio/fs/LinuxFileStore.java#91 > Wildfly Stack Overflow issue, not solved: > https://stackoverflow.com/questions/41022393/mount-point-not-found > Background Info: > http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html > A) chroot environment [1] > B) Docker container with overlay and overlay2 storage drivers [2] > C) btrfs file system with an unmounted sub-volume [2] > [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment > [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker > Docker file system/storage driver: > https://docs.docker.com/engine/userguide/storagedriver/selectadriver/) > Yum yum-plugin-ovl, similar problem: > https://github.com/CentOS/sig-cloud-instance-images/issues/15 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 3 19:21:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 3 Mar 2017 19:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the jboss-logging-annotations dependency where it is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFCORE-1965: ---------------------------------- Summary: Remove the jboss-logging-annotations dependency where it is not used (was: Remove the jboss-logging-annotations dependency from the core feature pack.) > Remove the jboss-logging-annotations dependency where it is not used > -------------------------------------------------------------------- > > Key: WFCORE-1965 > URL: https://issues.jboss.org/browse/WFCORE-1965 > Project: WildFly Core > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: James Perkins > Priority: Critical > Fix For: 3.0.0.Beta8 > > > This was added inadvertently with some other changes: - > {noformat} > > org.jboss.logging > jboss-logging-annotations > > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 4 08:01:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sat, 4 Mar 2017 08:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372634#comment-13372634 ] Brian Stansberry commented on WFCORE-1351: ------------------------------------------ Hmm, so there isn't a WFLY issue for this, as this is WFLY-5989 moved to core. > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: Ivo Studensky > Priority: Critical > Fix For: 3.0.0.Beta8 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 4 08:02:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sat, 4 Mar 2017 08:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8289) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFCORE-1351 to WFLY-8289: ------------------------------------------------ Project: WildFly (was: WildFly Core) Key: WFLY-8289 (was: WFCORE-1351) Component/s: Remoting Security (was: Remoting) (was: Security) Fix Version/s: (was: 3.0.0.Beta8) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-8289 > URL: https://issues.jboss.org/browse/WFLY-8289 > Project: WildFly > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: Ivo Studensky > Priority: Critical > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 4 08:58:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sat, 4 Mar 2017 08:58:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7618) Fix code to not use default platform dependant encoding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372644#comment-13372644 ] Brian Stansberry commented on WFLY-7618: ---------------------------------------- [~ctomc] Can you link or attach that analysis? > Fix code to not use default platform dependant encoding > ------------------------------------------------------- > > Key: WFLY-7618 > URL: https://issues.jboss.org/browse/WFLY-7618 > Project: WildFly > Issue Type: Task > Reporter: Rostislav Svoboda > Assignee: Tomaz Cerar > > WFLY codebase depends in some cases on system default encoding. This should be fixed to use de facto standard UTF8. > This JIRA is followup of WFCORE-1510 in the main codebase. Main concern (proven by history too) is Windows. > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 4 23:08:00 2017 From: issues at jboss.org (Cheng Fang (JIRA)) Date: Sat, 4 Mar 2017 23:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8276) Upgrade JBeret from 1.2.2.Final to 1.2.3.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372681#comment-13372681 ] Cheng Fang commented on WFLY-8276: ---------------------------------- JBeret 1.2.3.Final is now out. For details, see JIRA release info: https://issues.jboss.org/projects/JBERET/versions/12333072 > Upgrade JBeret from 1.2.2.Final to 1.2.3.Final > ---------------------------------------------- > > Key: WFLY-8276 > URL: https://issues.jboss.org/browse/WFLY-8276 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > Once JBeret 1.2.3.Final is released and upgrade of the component should be done. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 09:46:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sun, 5 Mar 2017 09:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8290) Switch to using Elytron Subsystem from WildFly Core In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8290: -------------------------------------- Summary: Switch to using Elytron Subsystem from WildFly Core Key: WFLY-8290 URL: https://issues.jboss.org/browse/WFLY-8290 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 10:04:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 5 Mar 2017 10:04:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8137) Credential store alias with upper-case letters can't be added when Java assertions are enabled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFLY-8137: -------------------------------------- Assignee: Brian Stansberry (was: Darran Lofthouse) The downstream JIRA is unassigned, so I'm assigning it to myself. > Credential store alias with upper-case letters can't be added when Java assertions are enabled > ---------------------------------------------------------------------------------------------- > > Key: WFLY-8137 > URL: https://issues.jboss.org/browse/WFLY-8137 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Brian Stansberry > Priority: Critical > > When Java assertions are enable then adding credential store entry (alias) with upper case letters fails with assertion error. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 11:42:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Sun, 5 Mar 2017 11:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1456) Improve error messages and error handling on DMN compilation and execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1456: ---------------------------------- Description: This is a placeholder ticket for several small improvements on the error messages and error handling. 1. When a decision or a BKM has no expression, it raises the message ?No expression defined for node ?_guid??. Would it be possible to put the node name when one is defined instead? 2. Add the DMN model object reference to the DMNMessage class. 3. Avoid NPE and NoSuchElementException when a function or decision table returns null as result. was: This is a placeholder ticket for several small improvements on the error messages and error handling. 1. When a decision or a BKM has no expression, it raises the message ?No expression defined for node ?_guid??. Would it be possible to put the node name when one is defined instead? 2. Add the DMN model object reference to the DMNMessage class. > Improve error messages and error handling on DMN compilation and execution > -------------------------------------------------------------------------- > > Key: DROOLS-1456 > URL: https://issues.jboss.org/browse/DROOLS-1456 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Beta6 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > This is a placeholder ticket for several small improvements on the error messages and error handling. > 1. When a decision or a BKM has no expression, it raises the message ?No expression defined for node ?_guid??. Would it be possible to put the node name when one is defined instead? > 2. Add the DMN model object reference to the DMNMessage class. > 3. Avoid NPE and NoSuchElementException when a function or decision table returns null as result. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 12:00:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Sun, 5 Mar 2017 12:00:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8291) Mod_cluster operation descriptions only refer to Apache httpd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-9304 to WFLY-8291: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8291 (was: JBEAP-9304) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: mod_cluster (was: mod_cluster) Affects Version/s: (was: 7.1.0.DR10) > Mod_cluster operation descriptions only refer to Apache httpd > ------------------------------------------------------------- > > Key: WFLY-8291 > URL: https://issues.jboss.org/browse/WFLY-8291 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Please repair description in following operations as they are outdated, undertow proxy > is able to process this messages. > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "disable", > "description" => "Tell Apache httpd that all contexts of the node can't process new requests.", > "request-properties" => {}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "disable-context", > "description" => "Tell Apache httpd that the context can't process new requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "enable", > "description" => "Tell Apache httpd that all contexts of the node are ready receive requests.", > "request-properties" => {}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "enable-context", > "description" => "Tell Apache httpd that the context is ready receive requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "Virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "Context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "stop", > "description" => "Tell Apache httpd that all contexts of the node can't process requests.", > "request-properties" => {"waittime" => { > "type" => INT, > "description" => "wait timeout", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => 10, > "unit" => "SECONDS" > }}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "stop-context", > "description" => "Tell Apache httpd that the context can't process requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "Virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "Context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "waittime" => { > "type" => INT, > "description" => "wait timeout", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => 10, > "unit" => "SECONDS" > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 12:00:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Sun, 5 Mar 2017 12:00:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8291) Mod_cluster operation descriptions only refer to Apache httpd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8291: --------------------------------- Affects Version/s: 10.1.0.Final > Mod_cluster operation descriptions only refer to Apache httpd > ------------------------------------------------------------- > > Key: WFLY-8291 > URL: https://issues.jboss.org/browse/WFLY-8291 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Please repair description in following operations as they are outdated, undertow proxy > is able to process this messages. > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "disable", > "description" => "Tell Apache httpd that all contexts of the node can't process new requests.", > "request-properties" => {}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "disable-context", > "description" => "Tell Apache httpd that the context can't process new requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "enable", > "description" => "Tell Apache httpd that all contexts of the node are ready receive requests.", > "request-properties" => {}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "enable-context", > "description" => "Tell Apache httpd that the context is ready receive requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "Virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "Context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "stop", > "description" => "Tell Apache httpd that all contexts of the node can't process requests.", > "request-properties" => {"waittime" => { > "type" => INT, > "description" => "wait timeout", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => 10, > "unit" => "SECONDS" > }}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "stop-context", > "description" => "Tell Apache httpd that the context can't process requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "Virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "Context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "waittime" => { > "type" => INT, > "description" => "wait timeout", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => 10, > "unit" => "SECONDS" > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 22:33:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 5 Mar 2017 22:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7496) Non complete resource description In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas reopened WFLY-7496: ---------------------------------- > Non complete resource description > --------------------------------- > > Key: WFLY-7496 > URL: https://issues.jboss.org/browse/WFLY-7496 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 11.0.0.Alpha1 > > > Missing time unit > {noformat} > "session-timeout" => { > "type" => INT, > "description" => "The session timeout for sessions that are owned by crawlers", > "expressions-allowed" => true, > "nillable" => true, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > "timeout" => { > "type" => INT, > "description" => "The request timeout", > "expressions-allowed" => false, > "nillable" => true, > "access-type" => "read-only", > "storage" => "runtime" > "connection-idle-timeout" => { > "type" => INT, > "description" => "The amount of time a connection can be idle before it will be closed. Connections will not time out once the pool size is down to the configured minimum (as configured by cached-connections-per-thread)", > "expressions-allowed" => true, > "nillable" => true, > "default" => 60L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > "max-request-time" => { > "type" => INT, > "description" => "The maximum time that a proxy request can be active for, before being killed. Defaults to unlimited", > "expressions-allowed" => true, > "nillable" => true, > "default" => -1, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > {noformat} > Description not fully understandable > {noformat} > "require-host-http11" => { > "type" => BOOLEAN, > "description" => "Require the Host header when using the HTTP/1.1 protocol", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > "proxy-address-forwarding" => { > "type" => BOOLEAN, > "description" => "enables x-forwarded-host and similar headers and set a remote ip address and hostname", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > {noformat} > Name X Description > {noformat} > "disabled" => { > "type" => BOOLEAN, > "description" => "Enable the JSP container.", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 00:39:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Mon, 6 Mar 2017 00:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8292) Upgrade JACC to jboss-jacc-api_1.5_spec-1.0.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9306 to WFLY-8292: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8292 (was: JBEAP-9306) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Upgrade JACC to jboss-jacc-api_1.5_spec-1.0.1.Final > --------------------------------------------------- > > Key: WFLY-8292 > URL: https://issues.jboss.org/browse/WFLY-8292 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 02:22:01 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 6 Mar 2017 02:22:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8228: ----------------------------- Original Estimate: 1 day Remaining Estimate: 1 day > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Original Estimate: 1 day > Remaining Estimate: 1 day > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:02:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Mon, 6 Mar 2017 03:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-48) Prepare, run and atomate installation and upgrade testcases for h-services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan updated HAWKULARQE-48: ------------------------------------- Labels: hawkular-qe-upstream (was: ) > Prepare, run and atomate installation and upgrade testcases for h-services > -------------------------------------------------------------------------- > > Key: HAWKULARQE-48 > URL: https://issues.jboss.org/browse/HAWKULARQE-48 > Project: Hawkular QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: mfoley user > Labels: hawkular-qe-upstream > > We need to cover cases like https://bugzilla.redhat.com/show_bug.cgi?id=1418099 and https://issues.jboss.org/browse/HWKALERTS-220, installation of more h-services nodes + more cassandra nodes. > # prepare test cases in polarion: positive, negative, edge cases > # run those test cases > # automate them -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:04:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Mon, 6 Mar 2017 03:04:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-56) Middleware Manager: Rolling upgrades (on Kubernetes) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-56: ---------------------------------------- Assignee: Hayk Hovsepyan (was: mfoley user) > Middleware Manager: Rolling upgrades (on Kubernetes) > ---------------------------------------------------- > > Key: HAWKULARQE-56 > URL: https://issues.jboss.org/browse/HAWKULARQE-56 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Information from Heiko: > This may be less of a need to Hawkular-Metrics > in OS-Enterprise where people do some install > from scratch, but I guess with the OS-Online 1st > effort, we will deliver more releases in a quicker > cadence, where the chance of such a rollback > increases. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:21:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Mon, 6 Mar 2017 03:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8293) Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state In-Reply-To: References: Message-ID: Ondrej Lukas created WFLY-8293: ---------------------------------- Summary: Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state Key: WFLY-8293 URL: https://issues.jboss.org/browse/WFLY-8293 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse If I try to change Elytron default-authentication-context with header {{allow-resource-service-restart=true}} server ends in reload-required state. {code} /subsystem=elytron/authentication-context=auth-context:add() /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context){allow-resource-service-restart=true} { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} Using header allow-resource-service-restart=true should restart necessary services. It seems it is caused by {{"restart-required" => "no-services"}} for {{default-authentication-context}} attribute of Elytron subsystem. See: {code} /subsystem=elytron:read-resource-description(recursive=false) { ... "default-authentication-context" => { "type" => STRING, "description" => "The default authentication context to be associated with all deployments.", "expressions-allowed" => false, "required" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.authentication-context", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, ... } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:25:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Mon, 6 Mar 2017 03:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8294) credential-reference must have defined combinations of constraints In-Reply-To: References: Message-ID: Hynek ?v?bek created WFLY-8294: ---------------------------------- Summary: credential-reference must have defined combinations of constraints Key: WFLY-8294 URL: https://issues.jboss.org/browse/WFLY-8294 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse credential-reference must have defined these combinations of constraints: requires constraint: ??alias "requires" [store], ??store "requires" [alias] alternatives constraint: ??clear-text "alternatives" [store] ??store "alternatives" [clear-text] optional: type -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:45:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Mon, 6 Mar 2017 03:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8295) Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true In-Reply-To: References: Message-ID: Martin Choma created WFLY-8295: ---------------------------------- Summary: Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true Key: WFLY-8295 URL: https://issues.jboss.org/browse/WFLY-8295 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical On IBM java when obtain-kerberos-ticket is set to true user always get {code} javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible {code} According to ibm documentation [1] credsType=initiator and useKeytab are really incompatible. This constraint can't be avoided once obtain-kerberos-ticket = true, because keytab path is required in model. {code} "path" => { "type" => STRING, "description" => "The path of the KeyTab to load to obtain the credential.", "attribute-group" => "file", "expressions-allowed" => true, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {code} And keytab is always set into Kerberos login module options {code:title=GSSCredentialSecurityFactory.java} if (IS_IBM) { options.put("noAddress", "true"); options.put("credsType", (isServer && !obtainKerberosTicket) ? "acceptor" : "initiator"); options.put("useKeytab", keyTab.toURI().toURL().toString()); } {code} [1] https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jgssDocs/jaas_login_user.html I am not setting to blocker just because I am not sure about importance of obtain-kerberos-ticket. See my question JBEAP-9292. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:46:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Mon, 6 Mar 2017 03:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8295) Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFLY-8295: ------------------------------- Steps to Reproduce: * On IBM java * Follow https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildFlyElytronSecurity-ConfigureAuthenticationwithaKerberosBasedIdentityStore * During adding kerberos-security-factory add obtain-kerberos-ticket = true option {code} /subsystem=elytron/kerberos-security-factory=krbSF:add( \ principal="HTTP/host at REALM", \ path="/path/to/http.keytab", \ obtain-kerberos-ticket="true", \ mechanism-oids=[ \ 1.2.840.113554.1.2.2, \ 1.3.6.1.5.5.2 \ ] \ ) {code} was: * On IBM java * Follow https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1.alpha/html-single/how_to_set_up_sso_with_kerberos/#configure_the_elytron_subsystem * In step 2.4.1.1 during adding kerberos-security-factory add obtain-kerberos-ticket = true option {code} /subsystem=elytron/kerberos-security-factory=krbSF:add( \ principal="HTTP/host at REALM", \ path="/path/to/http.keytab", \ obtain-kerberos-ticket="true", \ mechanism-oids=[ \ 1.2.840.113554.1.2.2, \ 1.3.6.1.5.5.2 \ ] \ ) {code} > Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true > ---------------------------------------------------------------------------------------- > > Key: WFLY-8295 > URL: https://issues.jboss.org/browse/WFLY-8295 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: ibm-java, kerberos > > On IBM java when obtain-kerberos-ticket is set to true user always get > {code} > javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible > {code} > According to ibm documentation [1] credsType=initiator and useKeytab are really incompatible. > This constraint can't be avoided once obtain-kerberos-ticket = true, because keytab path is required in model. > {code} > "path" => { > "type" => STRING, > "description" => "The path of the KeyTab to load to obtain the credential.", > "attribute-group" => "file", > "expressions-allowed" => true, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > And keytab is always set into Kerberos login module options > {code:title=GSSCredentialSecurityFactory.java} > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", (isServer && !obtainKerberosTicket) ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > } > {code} > [1] https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jgssDocs/jaas_login_user.html > I am not setting to blocker just because I am not sure about importance of obtain-kerberos-ticket. See my question JBEAP-9292. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:05:01 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Mon, 6 Mar 2017 04:05:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8293) Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFLY-8293: ------------------------------- Description: If I try to change Elytron default-authentication-context server ends in reload-required state. {code} /subsystem=elytron/authentication-context=auth-context:add() /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model {code} /subsystem=elytron:read-resource-description(recursive=false) { ... "default-authentication-context" => { "type" => STRING, "description" => "The default authentication context to be associated with all deployments.", "expressions-allowed" => false, "required" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.authentication-context", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, ... } {code} According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary no-services ? Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model was: If I try to change Elytron default-authentication-context with header {{allow-resource-service-restart=true}} server ends in reload-required state. {code} /subsystem=elytron/authentication-context=auth-context:add() /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context){allow-resource-service-restart=true} { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} Using header allow-resource-service-restart=true should restart necessary services. It seems it is caused by {{"restart-required" => "no-services"}} for {{default-authentication-context}} attribute of Elytron subsystem. See: {code} /subsystem=elytron:read-resource-description(recursive=false) { ... "default-authentication-context" => { "type" => STRING, "description" => "The default authentication context to be associated with all deployments.", "expressions-allowed" => false, "required" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.authentication-context", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, ... } {code} > Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8293 > URL: https://issues.jboss.org/browse/WFLY-8293 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > If I try to change Elytron default-authentication-context server ends in reload-required state. > {code} > /subsystem=elytron/authentication-context=auth-context:add() > /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model > {code} > /subsystem=elytron:read-resource-description(recursive=false) > { > ... > "default-authentication-context" => { > "type" => STRING, > "description" => "The default authentication context to be associated with all deployments.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.authentication-context", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > ... > } > {code} > According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary > no-services ? Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:06:01 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Mon, 6 Mar 2017 04:06:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8293) Changing Elytron default-authentication-context ends in reload-required state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFLY-8293: ------------------------------- Summary: Changing Elytron default-authentication-context ends in reload-required state (was: Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state) > Changing Elytron default-authentication-context ends in reload-required state > ----------------------------------------------------------------------------- > > Key: WFLY-8293 > URL: https://issues.jboss.org/browse/WFLY-8293 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > If I try to change Elytron default-authentication-context server ends in reload-required state. > {code} > /subsystem=elytron/authentication-context=auth-context:add() > /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model > {code} > /subsystem=elytron:read-resource-description(recursive=false) > { > ... > "default-authentication-context" => { > "type" => STRING, > "description" => "The default authentication context to be associated with all deployments.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.authentication-context", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > ... > } > {code} > According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary > no-services ? Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:20:03 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Mon, 6 Mar 2017 04:20:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8296) CredentialStore, set own security provider through java security config file leads to NoClassDefFoundError for custom implementation class In-Reply-To: References: Message-ID: Hynek ?v?bek created WFLY-8296: ---------------------------------- Summary: CredentialStore, set own security provider through java security config file leads to NoClassDefFoundError for custom implementation class Key: WFLY-8296 URL: https://issues.jboss.org/browse/WFLY-8296 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse When I want to define own Custom Elytron Provider through modification of Java security provider configuration I got exception about NoClassDefFoundError on CustomImplementation class. But this class is located in same jar file as Custom Elytron Provider. I need it to define provider-name in credential-store. Is there some additional step which I missed? Jar file is attached and it is same one as here https://issues.jboss.org/browse/JBEAP-8238 from [~pskopek] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:38:01 2017 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Mon, 6 Mar 2017 04:38:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8294) credential-reference must have defined combinations of constraints In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372863#comment-13372863 ] Michal Petrov commented on WFLY-8294: ------------------------------------- FYI, nested attributes are currently not validated for constraints - WFCORE-2317. > credential-reference must have defined combinations of constraints > ------------------------------------------------------------------ > > Key: WFLY-8294 > URL: https://issues.jboss.org/browse/WFLY-8294 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > credential-reference must have defined these combinations of constraints: > requires constraint: > ??alias "requires" [store], > ??store "requires" [alias] > alternatives constraint: > ??clear-text "alternatives" [store] > ??store "alternatives" [clear-text] > optional: type -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:41:00 2017 From: issues at jboss.org (ted won (JIRA)) Date: Mon, 6 Mar 2017 04:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ted won updated WFCORE-2011: ---------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2001, https://github.com/wildfly/wildfly/pull/9745 (was: https://github.com/wildfly/wildfly-core/pull/2001) > Inconsistency of formatter and named-formatter in console logging handler > ------------------------------------------------------------------------- > > Key: WFCORE-2011 > URL: https://issues.jboss.org/browse/WFCORE-2011 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha13 > Environment: It is possible to reproduce with all profiles and all modes. > All WildFly profiles > All WildFly clustering mode > * standalone mode > * domain mode > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: logging > Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png > > > In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter. > And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} > It is working as it is defined with colors in a console. > {code:title=standalone.xml} > ... > > > > > > > > ... > > > > > ... > {code} > However there is a inconsistency in the CLI and WildFly admin console views. > In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console. > {code:title=JBoss CLI} > [standalone at localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n", > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} > It should be fixed like below: > {code:title=Expected result} > [standalone at localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => undefined, > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1419) Make interface AccumulateFunction to avoid downcasting verbosity in implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-1419: ------------------------------------------- Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Make interface AccumulateFunction to avoid downcasting verbosity in implementations > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1419 > URL: https://issues.jboss.org/browse/DROOLS-1419 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > Priority: Minor > Fix For: 7.0.0.Beta8 > > > Fix will NOT break backwards compatibility. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-817) Extremely poor performance of the topological sorting implementation for type declarations performs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-817: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Extremely poor performance of the topological sorting implementation for type declarations performs > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-817 > URL: https://issues.jboss.org/browse/DROOLS-817 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.Beta1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 7.0.0.Beta8 > > > The current implementation suffers from thrashing. > In case of large business object models (e.g. derived from an ontology), > the analysis at package build time may take orders of magnitude more > than necessary -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-744) Rule Generation Feature Request In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-744: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Rule Generation Feature Request > ------------------------------- > > Key: DROOLS-744 > URL: https://issues.jboss.org/browse/DROOLS-744 > Project: Drools > Issue Type: Feature Request > Components: core engine, kie server > Affects Versions: 6.2.0.Final > Reporter: Justin Holmes > Assignee: Mario Fusco > Fix For: 7.0.0.Beta8 > > > As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems. > The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-680) "contains" operator behaves inconsistently when used with Maps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-680: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > "contains" operator behaves inconsistently when used with Maps > -------------------------------------------------------------- > > Key: DROOLS-680 > URL: https://issues.jboss.org/browse/DROOLS-680 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 7.0.0.Beta8 > > > In a rule > {code} > Bean( map contains "x" ) // assuming "map" is a property of type Map > {code} > "contains" is arbitrarily interpreted as "containsKey" > The constrain will then fail after being jitted > The documentation explicitly states that "contains" applies to collections -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-670) Generalize inline casts to work with traits In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-670: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Generalize inline casts to work with traits > ------------------------------------------- > > Key: DROOLS-670 > URL: https://issues.jboss.org/browse/DROOLS-670 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.Beta8 > > > The following constraint > {code} > Person( this#Worker( wage > 1000 ) ) > {code} > is admissible when Worker is a subtype of Person. > It should also be possible to use "#" when Worker is a donned trait. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:03 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-607) Match.getObjects() should reflect the patterns' order In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-607: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Match.getObjects() should reflect the patterns' order > ----------------------------------------------------- > > Key: DROOLS-607 > URL: https://issues.jboss.org/browse/DROOLS-607 > Project: Drools > Issue Type: Enhancement > Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final > Reporter: Davide Sottara > Assignee: Mark Proctor > Priority: Minor > Fix For: 7.0.0.Beta8 > > > if Match.getObjects() is called on a rule with LHS A() B() C(), > the resulting list will have the matching objects in reversed order > - that is, [c, b, a] - making it more difficult to analyze it. > The object's position in the list should reflect the LHS. > The order should be preserved even when subnetworks are present. > For example, A() not B() C() should then result in the list [a, *, c ] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-669: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Create "behavesAs" operator to support traiting > ----------------------------------------------- > > Key: DROOLS-669 > URL: https://issues.jboss.org/browse/DROOLS-669 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.Beta8 > > > Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:03 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-470) Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-470: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) > --------------------------------------------------------------------------------------------------- > > Key: DROOLS-470 > URL: https://issues.jboss.org/browse/DROOLS-470 > Project: Drools > Issue Type: Enhancement > Components: decision tables > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Anstis > Labels: optaplanner-request-for-drools > Fix For: 7.0.0.Beta8 > > > This DT should work: > ||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))|| > |guestName == "$param"|guestName == "$param"|doSomething();| > It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed. > Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule: > ||CONDITION||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation()||| > |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();| > Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:03 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-542) Expose more Commands through the KieCommands API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-542: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Expose more Commands through the KieCommands API > ------------------------------------------------ > > Key: DROOLS-542 > URL: https://issues.jboss.org/browse/DROOLS-542 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.1.0.CR1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.Beta8 > > > Not all Commands are exposed by the KieCommands API interface -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:42:03 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 06:42:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals configurable via kmodule.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-453: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Allow KieSession globals configurable via kmodule.xml > ----------------------------------------------------- > > Key: DROOLS-453 > URL: https://issues.jboss.org/browse/DROOLS-453 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.0.0.Final > Reporter: Anton Giertli > Assignee: Mark Proctor > Fix For: 7.0.0.Beta8 > > > Looking at the current xsd of kmodule.xml > https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd > It is not possible to configure KieSession globals variables via kmodule.xml. > Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 07:35:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Mon, 6 Mar 2017 07:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-45) Setup Jenkins Slave server on openstack to run cf-ui smoke test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373064#comment-13373064 ] Sunil kondkar commented on HAWKULARQE-45: ----------------------------------------- Issues with setup.sh are resolved. Chrome issues resolved by updating the chromedriver with latest version(2.27). The latest smoke run is pass: http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/miq-ms-cfui-nightly/172/console The only issue remaining is with vncviewer otherwise the task is complete. > Setup Jenkins Slave server on openstack to run cf-ui smoke test suite > --------------------------------------------------------------------- > > Key: HAWKULARQE-45 > URL: https://issues.jboss.org/browse/HAWKULARQE-45 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > At present Jenkins slave is on BC and sometimes smoke test suites fai due to timeout issue. This task is to setup Jenkins slave on openstack instance. > Install: > Python > Chrome/FF > Headless Selenium > xvfb > connect via vnc -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 07:38:06 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Mon, 6 Mar 2017 07:38:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8294) credential-reference must have defined combinations of constraints In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFLY-8294: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > credential-reference must have defined combinations of constraints > ------------------------------------------------------------------ > > Key: WFLY-8294 > URL: https://issues.jboss.org/browse/WFLY-8294 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > credential-reference must have defined these combinations of constraints: > requires constraint: > ??alias "requires" [store], > ??store "requires" [alias] > alternatives constraint: > ??clear-text "alternatives" [store] > ??store "alternatives" [clear-text] > optional: type -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 07:55:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Mon, 6 Mar 2017 07:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8297) Upgrade HAL to 2.9.4.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-8297: --------------------------------- Summary: Upgrade HAL to 2.9.4.Final Key: WFLY-8297 URL: https://issues.jboss.org/browse/WFLY-8297 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 07:55:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Mon, 6 Mar 2017 07:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8297) Upgrade HAL to 2.9.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-8297: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9705) > Upgrade HAL to 2.9.4.Final > -------------------------- > > Key: WFLY-8297 > URL: https://issues.jboss.org/browse/WFLY-8297 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 07:59:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Mon, 6 Mar 2017 07:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AG-12) Add OSGi bundle metadata In-Reply-To: References: Message-ID: Luis Barreiro created AG-12: ------------------------------- Summary: Add OSGi bundle metadata Key: AG-12 URL: https://issues.jboss.org/browse/AG-12 Project: Agroal Issue Type: Bug Components: build Affects Versions: 0.1 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 0.2 JARs currently miss the metadata required to be loaded in OSGi containers -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:19:00 2017 From: issues at jboss.org (Dmitrii Tikhomirov (JIRA)) Date: Mon, 6 Mar 2017 08:19:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8298) Not able to undefine initial-pool-size attribute of datasource In-Reply-To: References: Message-ID: Dmitrii Tikhomirov created WFLY-8298: ---------------------------------------- Summary: Not able to undefine initial-pool-size attribute of datasource Key: WFLY-8298 URL: https://issues.jboss.org/browse/WFLY-8298 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 10.1.0.Final Reporter: Dmitrii Tikhomirov Assignee: Dmitrii Tikhomirov Priority: Blocker {code} /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=initial-pool-size) { "outcome" => "failed", "failure-description" => "WFLYJCA0045: failed to set attribute: null", "rolled-back" => true } {code} This is regression compared to EAP 7.0.0.GA as well as 7.1.0.DR12. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:20:01 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Mon, 6 Mar 2017 08:20:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8299) There is missing CS integration with core management In-Reply-To: References: Message-ID: Hynek ?v?bek created WFLY-8299: ---------------------------------- Summary: There is missing CS integration with core management Key: WFLY-8299 URL: https://issues.jboss.org/browse/WFLY-8299 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Priority: Blocker Priority is BLOCKER because this issue blocks RFE verification https://issues.jboss.org/browse/EAP7-538 There must be credential store integration with core management as is mentioned in requirements of RFE. *management/security-realm* *management/security-realm/authentication/truststore* keystore-password *management/security-realm/server-identity/ssl* key-password and keystore-password *management/security-realm/server-identity/secret* *management/security-realm/authentication/users* But *security-realm* is deprecated, these resources have this description: {code} The security-realm configuration is deprecated and may be removed or moved in future versions. {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:23:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Mon, 6 Mar 2017 08:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AG-13) Fix the classloader used for loading the implementation In-Reply-To: References: Message-ID: Luis Barreiro created AG-13: ------------------------------- Summary: Fix the classloader used for loading the implementation Key: AG-13 URL: https://issues.jboss.org/browse/AG-13 Project: Agroal Issue Type: Bug Components: api Affects Versions: 0.1 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 0.2 Currently {{AgroalDataSource}} uses the thread context classloader. It should use the classloader of the class instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:25:00 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Mon, 6 Mar 2017 08:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer reassigned DROOLS-1048: ---------------------------------------------- Assignee: Michael Biarnes Kiefer (was: Petr ?irok?) > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > Preparation: > 1) Get some experience > - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from droolsjbpm > -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 3) Set up roles and users of github.com/kiegroup. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be moving the first repository. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - You can do one repository at a time, or do multiple at the same time. > -- I'd recommend to start with just 1 to get a feel for it. > - Do them in reverse order of the repository-list.txt! > - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. > -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. > -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. > - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. > - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. > 6) Clean up the fallout > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:31:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Mon, 6 Mar 2017 08:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AG-13) Fix the classloader used for loading the implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AG-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Barreiro resolved AG-13. ----------------------------- Resolution: Done > Fix the classloader used for loading the implementation > ------------------------------------------------------- > > Key: AG-13 > URL: https://issues.jboss.org/browse/AG-13 > Project: Agroal > Issue Type: Bug > Components: api > Affects Versions: 0.1 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.2 > > > Currently {{AgroalDataSource}} uses the thread context classloader. It should use the classloader of the class instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:31:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Mon, 6 Mar 2017 08:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AG-12) Add OSGi bundle metadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AG-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Barreiro resolved AG-12. ----------------------------- Resolution: Done > Add OSGi bundle metadata > ------------------------ > > Key: AG-12 > URL: https://issues.jboss.org/browse/AG-12 > Project: Agroal > Issue Type: Bug > Components: build > Affects Versions: 0.1 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.2 > > > JARs currently miss the metadata required to be loaded in OSGi containers -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:05:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Mon, 6 Mar 2017 09:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2311) System property wildfly.config.url doesn't resolve correctly relative paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek resolved WFCORE-2311. --------------------------------- Resolution: Done Fixing status - to be aligned with downstream (which is now Verified). > System property wildfly.config.url doesn't resolve correctly relative paths > --------------------------------------------------------------------------- > > Key: WFCORE-2311 > URL: https://issues.jboss.org/browse/WFCORE-2311 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > When an AS client runs with custom Elytron configuration specified and system property {{wildfly.config.url}} is used to provide the configuration (as a relative path), then the resolved URI is not correct. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:06:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Mon, 6 Mar 2017 09:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2311) System property wildfly.config.url doesn't resolve correctly relative paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFCORE-2311: -------------------------------- Fix Version/s: 3.0.0.Beta6 > System property wildfly.config.url doesn't resolve correctly relative paths > --------------------------------------------------------------------------- > > Key: WFCORE-2311 > URL: https://issues.jboss.org/browse/WFCORE-2311 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta6 > > > When an AS client runs with custom Elytron configuration specified and system property {{wildfly.config.url}} is used to provide the configuration (as a relative path), then the resolved URI is not correct. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:27:01 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Mon, 6 Mar 2017 09:27:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1048: ------------------------------------- Description: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. Preparation: 1) Get some experience - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from droolsjbpm -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 3) Set up roles and users of github.com/kiegroup. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be moving the first repository. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Rename the organization droolsjbpm to kiegroup - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? -OLD WAY - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.- 6) Clean up the fallout - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... was: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. Preparation: 1) Get some experience - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from droolsjbpm -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 3) Set up roles and users of github.com/kiegroup. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be moving the first repository. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. 6) Clean up the fallout - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > Preparation: > 1) Get some experience > - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from droolsjbpm > -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 3) Set up roles and users of github.com/kiegroup. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be moving the first repository. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Rename the organization droolsjbpm to kiegroup > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > -OLD WAY > - You can do one repository at a time, or do multiple at the same time. > -- I'd recommend to start with just 1 to get a feel for it. > - Do them in reverse order of the repository-list.txt! > - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. > -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. > -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. > - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. > - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.- > 6) Clean up the fallout > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:29:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 6 Mar 2017 09:29:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8300) standalone-picketlink.xml boots with lots of errors In-Reply-To: References: Message-ID: Tomaz Cerar created WFLY-8300: --------------------------------- Summary: standalone-picketlink.xml boots with lots of errors Key: WFLY-8300 URL: https://issues.jboss.org/browse/WFLY-8300 Project: WildFly Issue Type: Bug Components: Security Reporter: Tomaz Cerar Assignee: Darran Lofthouse If you try to run standalone-picketlink.xml server configuration, it's boot fails with lots of problems. They look related to elytron changes, but I am not sure. {noformat} 15:27:36,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "picketlink-identity-management"), ("partition-manager" => "jpa.emf.modules.partition.manager") ]) - failure description: { "WFLYCTL0080: Failed services" => {"jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store" => "org.jboss.msc.service.StartException in service jb oss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store: Failed to start service Caused by: org.picketlink.idm.config.SecurityConfigurationException: WFLYPL0050: Entities module not found [my.module]."}, "WFLYCTL0412: Required services that are not installed:" => ["jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store"] } 15:27:36,477 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "undertow"), ("server" => "default-server"), ("host" => "default-host"), ("setting" => "http-invoker") ]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory. application-http-authentication]"] } {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:34:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 09:34:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8300) standalone-picketlink.xml boots with lots of errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373248#comment-13373248 ] Darran Lofthouse commented on WFLY-8300: ---------------------------------------- This issue is a good illustration of why we don't have a standalone-elytron.xml anymore and why I would be reluctant to add it back. We have these specialist configurations but they are not used within the testsuite so although we probably broke this a long time ago it is only just discovered now. > standalone-picketlink.xml boots with lots of errors > --------------------------------------------------- > > Key: WFLY-8300 > URL: https://issues.jboss.org/browse/WFLY-8300 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > If you try to run standalone-picketlink.xml server configuration, it's boot fails with lots of problems. They look related to elytron changes, but I am not sure. > {noformat} > 15:27:36,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "picketlink-identity-management"), > ("partition-manager" => "jpa.emf.modules.partition.manager") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store" => "org.jboss.msc.service.StartException in service jb > oss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store: Failed to start service > Caused by: org.picketlink.idm.config.SecurityConfigurationException: WFLYPL0050: Entities module not found [my.module]."}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store"] > } > 15:27:36,477 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory. > application-http-authentication]"] > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:54:01 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Mon, 6 Mar 2017 09:54:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1048: ------------------------------------- Description: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. Preparation: 1) Get some experience - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from foo_org -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? More stuff to try: - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be renaming the org. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Freeze starts, announce in capitals on every IRC channel - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). - *Rename the organization droolsjbpm to kiegroup* - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? - Freeze stops, announce in capitals on every IRC channel -OLD WAY Don't do this any more: - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. OLD WAY END- 6) Clean up the fallout - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: -- all code -- openhub -- jira -- fisheye -- .org websites (incl jboss.properties) -- jboss.org - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... was: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. Preparation: 1) Get some experience - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from droolsjbpm -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 3) Set up roles and users of github.com/kiegroup. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be moving the first repository. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Rename the organization droolsjbpm to kiegroup - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? -OLD WAY - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.- 6) Clean up the fallout - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > Preparation: > 1) Get some experience > - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from foo_org > -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > More stuff to try: > - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? > 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be renaming the org. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Freeze starts, announce in capitals on every IRC channel > - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). > - *Rename the organization droolsjbpm to kiegroup* > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > - Freeze stops, announce in capitals on every IRC channel > -OLD WAY Don't do this any more: > - You can do one repository at a time, or do multiple at the same time. > -- I'd recommend to start with just 1 to get a feel for it. > - Do them in reverse order of the repository-list.txt! > - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. > -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. > -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. > - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. > - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. > OLD WAY END- > 6) Clean up the fallout > - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: > -- all code > -- openhub > -- jira > -- fisheye > -- .org websites (incl jboss.properties) > -- jboss.org > - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:54:02 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Mon, 6 Mar 2017 09:54:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164146#comment-13164146 ] Geoffrey De Smet edited comment on DROOLS-1048 at 3/6/17 9:53 AM: ------------------------------------------------------------------ Separate issue to be done later: *All repository names must match the artifactId of the root pom.* - repo droolsjbpm-knowledge must be renamed to ... - -pom drools-multiproject must be renamed to drools (to match rep drools)- etc This is important for automated scripts such as xmvn (which builds RPM's), as well as to adhere to maven standards (which are relied upon by maven site etc). was (Author: ge0ffrey): Extra requirement: *All repository names must match the artifactId of the root pom.* - repo droolsjbpm-knowledge must be renamed to ... - -pom drools-multiproject must be renamed to drools (to match rep drools)- etc This is important for automated scripts such as xmvn (which builds RPM's), as well as to adhere to maven standards (which are relied upon by maven site etc). > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > Preparation: > 1) Get some experience > - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from foo_org > -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > More stuff to try: > - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? > 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be renaming the org. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Freeze starts, announce in capitals on every IRC channel > - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). > - *Rename the organization droolsjbpm to kiegroup* > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > - Freeze stops, announce in capitals on every IRC channel > -OLD WAY Don't do this any more: > - You can do one repository at a time, or do multiple at the same time. > -- I'd recommend to start with just 1 to get a feel for it. > - Do them in reverse order of the repository-list.txt! > - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. > -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. > -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. > - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. > - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. > OLD WAY END- > 6) Clean up the fallout > - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: > -- all code > -- openhub > -- jira > -- fisheye > -- .org websites (incl jboss.properties) > -- jboss.org > - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 09:55:01 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Mon, 6 Mar 2017 09:55:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1048: ------------------------------------- Description: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. https://help.github.com/articles/renaming-an-organization/ Preparation: 1) Get some experience - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from foo_org -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? More stuff to try: - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be renaming the org. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Freeze starts, announce in capitals on every IRC channel - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? - Freeze stops, announce in capitals on every IRC channel -OLD WAY Don't do this any more: - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. OLD WAY END- 6) Clean up the fallout - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: -- all code -- openhub -- jira -- fisheye -- .org websites (incl jboss.properties) -- jboss.org - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... was: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. Preparation: 1) Get some experience - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from foo_org -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? More stuff to try: - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be renaming the org. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Freeze starts, announce in capitals on every IRC channel - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). - *Rename the organization droolsjbpm to kiegroup* - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? - Freeze stops, announce in capitals on every IRC channel -OLD WAY Don't do this any more: - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. OLD WAY END- 6) Clean up the fallout - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: -- all code -- openhub -- jira -- fisheye -- .org websites (incl jboss.properties) -- jboss.org - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > https://help.github.com/articles/renaming-an-organization/ > Preparation: > 1) Get some experience > - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from foo_org > -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > More stuff to try: > - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? > 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be renaming the org. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Freeze starts, announce in capitals on every IRC channel > - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). > - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > - Freeze stops, announce in capitals on every IRC channel > -OLD WAY Don't do this any more: > - You can do one repository at a time, or do multiple at the same time. > -- I'd recommend to start with just 1 to get a feel for it. > - Do them in reverse order of the repository-list.txt! > - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. > -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. > -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. > - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. > - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. > OLD WAY END- > 6) Clean up the fallout > - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: > -- all code > -- openhub > -- jira > -- fisheye > -- .org websites (incl jboss.properties) > -- jboss.org > - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:05:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Mon, 6 Mar 2017 10:05:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-912) Create DirContext is not able to log arrays correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reopened ELY-912: ---------------------------- > Create DirContext is not able to log arrays correctly > ----------------------------------------------------- > > Key: ELY-912 > URL: https://issues.jboss.org/browse/ELY-912 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta21 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Fix For: 1.1.0.Beta26 > > > In case when debug level for class {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder}} is enabled and value of any property from properties used for creating DirContext is array, then its value is not logged correctly, example: > {code} > Property [java.naming.security.credentials] with Value [[C at 1bf1b7d5] > {code} > See https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L320 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:08:00 2017 From: issues at jboss.org (Dmitrii Tikhomirov (JIRA)) Date: Mon, 6 Mar 2017 10:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8298) Not able to undefine initial-pool-size attribute of datasource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitrii Tikhomirov updated WFLY-8298: ------------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9747) > Not able to undefine initial-pool-size attribute of datasource > -------------------------------------------------------------- > > Key: WFLY-8298 > URL: https://issues.jboss.org/browse/WFLY-8298 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Dmitrii Tikhomirov > Assignee: Dmitrii Tikhomirov > Priority: Blocker > > {code} > /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=initial-pool-size) > { > "outcome" => "failed", > "failure-description" => "WFLYJCA0045: failed to set attribute: null", > "rolled-back" => true > } > {code} > This is regression compared to EAP 7.0.0.GA as well as 7.1.0.DR12. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:12:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 6 Mar 2017 10:12:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8299) There is missing CS integration with core management In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373340#comment-13373340 ] Brian Stansberry commented on WFLY-8299: ---------------------------------------- What is the bug here? The description is unclear to me. > There is missing CS integration with core management > ---------------------------------------------------- > > Key: WFLY-8299 > URL: https://issues.jboss.org/browse/WFLY-8299 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > Priority is BLOCKER because this issue blocks RFE verification https://issues.jboss.org/browse/EAP7-538 > There must be credential store integration with core management as is mentioned in requirements of RFE. > *management/security-realm* > *management/security-realm/authentication/truststore* keystore-password > *management/security-realm/server-identity/ssl* key-password and keystore-password > *management/security-realm/server-identity/secret* > *management/security-realm/authentication/users* > But *security-realm* is deprecated, these resources have this description: > {code} > The security-realm configuration is deprecated and may be removed or moved in future versions. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:16:00 2017 From: issues at jboss.org (Radovan Netuka (JIRA)) Date: Mon, 6 Mar 2017 10:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radovan Netuka updated SECURITY-921: ------------------------------------ Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/35, https://github.com/wildfly-security/jboss-negotiation/pull/36 (was: https://github.com/wildfly-security/jboss-negotiation/pull/35) > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:16:01 2017 From: issues at jboss.org (Radovan Netuka (JIRA)) Date: Mon, 6 Mar 2017 10:16:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373348#comment-13373348 ] Radovan Netuka commented on SECURITY-921: ----------------------------------------- PR for master branch: https://github.com/wildfly-security/jboss-negotiation/pull/36 > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:21:00 2017 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Mon, 6 Mar 2017 10:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8042) JAVASERVERFACES-3936 / JAVASERVERFACES-3152 / JAVASERVERFACES-3035 - JSF ui:repeat losing state on ajax requests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panagiotis Sotiropoulos closed WFLY-8042. ----------------------------------------- Resolution: Rejected > JAVASERVERFACES-3936 / JAVASERVERFACES-3152 / JAVASERVERFACES-3035 - JSF ui:repeat losing state on ajax requests > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8042 > URL: https://issues.jboss.org/browse/WFLY-8042 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Panagiotis Sotiropoulos > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:23:01 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 6 Mar 2017 10:23:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1048: ---------------------------------- Description: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. https://help.github.com/articles/renaming-an-organization/ Preparation: 1) Get some experience - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from foo_org -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and rename it from foo_org to foo_org_kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? More stuff to try: - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? 2) (Optional - not needed now that we are renaming org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be renaming the org. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Freeze starts, announce in capitals on every IRC channel - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? - Freeze stops, announce in capitals on every IRC channel 6) Clean up the fallout - Change the pom.xml scm tag for master (in all repo's that ref it) - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: -- all code -- openhub -- jira -- fisheye -- .org websites (incl jboss.properties) -- jboss.org - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... was: [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. https://help.github.com/articles/renaming-an-organization/ Preparation: 1) Get some experience - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: -- Once from foo_org -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") - Add some local changes on both dirs. - On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup. - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. -- What happened to the open PR? More stuff to try: - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? 2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. 4) Reach out - Talk to each type of person involved: -- R&D developer -- QA -- Productization -- Product docs -- Community - Make an inventory of references to "github.com/droolsjbpm" -- Do a find in path on all our files for "github.com/droolsjbpm") -- Which webapps reference it? --- jenkins --- jira --- www.openhub.net --- gitter --- stackoverflow --- google forums / mailing lists --- ... - Set a date when you'll be renaming the org. -- Clearly communicate on all channels to let everyone know. This includes: --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... --- Internal mailing lists: sme-brms, pm lists, bsig, etc --- IRC channel topics --- Social media (Twitter accounts etc) --- ... - Clearly communicate: -- What you'll do -- When you'll do it -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! -- A recipe: What they need to do - step by step for dummies - after the merge is done. -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. 5) Do it: - Freeze starts, announce in capitals on every IRC channel - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? - Freeze stops, announce in capitals on every IRC channel -OLD WAY Don't do this any more: - You can do one repository at a time, or do multiple at the same time. -- I'd recommend to start with just 1 to get a feel for it. - Do them in reverse order of the repository-list.txt! - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT. -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes. -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months. - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc. - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day. OLD WAY END- 6) Clean up the fallout - Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it) - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: -- all code -- openhub -- jira -- fisheye -- .org websites (incl jboss.properties) -- jboss.org - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > https://help.github.com/articles/renaming-an-organization/ > Preparation: > 1) Get some experience > - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from foo_org > -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and rename it from foo_org to foo_org_kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > More stuff to try: > - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? > 2) (Optional - not needed now that we are renaming org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be renaming the org. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Freeze starts, announce in capitals on every IRC channel > - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). > - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > - Freeze stops, announce in capitals on every IRC channel > 6) Clean up the fallout > - Change the pom.xml scm tag for master (in all repo's that ref it) > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: > -- all code > -- openhub > -- jira > -- fisheye > -- .org websites (incl jboss.properties) > -- jboss.org > - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:32:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Mon, 6 Mar 2017 10:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8299) There is missing CS integration with core management In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373378#comment-13373378 ] Hynek ?v?bek commented on WFLY-8299: ------------------------------------ [~brian.stansberry] RFE EAP7-538 has requirements to update core management to use credential store reference. This RFE had VERIFICATION TODO state yet. And this wasn't implemented yet. > There is missing CS integration with core management > ---------------------------------------------------- > > Key: WFLY-8299 > URL: https://issues.jboss.org/browse/WFLY-8299 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > Priority is BLOCKER because this issue blocks RFE verification https://issues.jboss.org/browse/EAP7-538 > There must be credential store integration with core management as is mentioned in requirements of RFE. > *management/security-realm* > *management/security-realm/authentication/truststore* keystore-password > *management/security-realm/server-identity/ssl* key-password and keystore-password > *management/security-realm/server-identity/secret* > *management/security-realm/authentication/users* > But *security-realm* is deprecated, these resources have this description: > {code} > The security-realm configuration is deprecated and may be removed or moved in future versions. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:06:00 2017 From: issues at jboss.org (Scott Van Wart (JIRA)) Date: Mon, 6 Mar 2017 11:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373414#comment-13373414 ] Scott Van Wart commented on WFLY-8217: -------------------------------------- I get exactly the same result with the snapshot (downloaded 30 minutes ago on March 6th, 2017). I'll attach the server.log. > ActiveMQ leaks connections if a JMS message is sent from an MDB > --------------------------------------------------------------- > > Key: WFLY-8217 > URL: https://issues.jboss.org/browse/WFLY-8217 > Project: WildFly > Issue Type: Bug > Components: JMS, Transactions > Affects Versions: 10.1.0.Final > Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14) > Reporter: Scott Van Wart > Assignee: Jeff Mesnil > Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log > > > If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test). > 1) Build the EAR > 2) Run wildfly with the standalone-full.xml configuration: > {{standalone.bat --server-config=standalone-full.xml}} > 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM: > {{jboss-cli.bat -c}} > {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}} > {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}} > 4) Deploy the EAR. > 5) Access http://localhost:8080/leak-web/rest/test?message=Hi > The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs > (see attached log.txt) > I have no idea why JIRA attached each file twice. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:06:00 2017 From: issues at jboss.org (Scott Van Wart (JIRA)) Date: Mon, 6 Mar 2017 11:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Van Wart updated WFLY-8217: --------------------------------- Attachment: server.log > ActiveMQ leaks connections if a JMS message is sent from an MDB > --------------------------------------------------------------- > > Key: WFLY-8217 > URL: https://issues.jboss.org/browse/WFLY-8217 > Project: WildFly > Issue Type: Bug > Components: JMS, Transactions > Affects Versions: 10.1.0.Final > Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14) > Reporter: Scott Van Wart > Assignee: Jeff Mesnil > Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log > > > If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test). > 1) Build the EAR > 2) Run wildfly with the standalone-full.xml configuration: > {{standalone.bat --server-config=standalone-full.xml}} > 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM: > {{jboss-cli.bat -c}} > {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}} > {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}} > 4) Deploy the EAR. > 5) Access http://localhost:8080/leak-web/rest/test?message=Hi > The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs > (see attached log.txt) > I have no idea why JIRA attached each file twice. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:14:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 6 Mar 2017 11:14:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8228: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9748 (was: https://github.com/wildfly/wildfly/pull/9744) > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:14:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 6 Mar 2017 11:14:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8228: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9748, https://github.com/wildfly-security-incubator/wildfly/pull/141 (was: https://github.com/wildfly/wildfly/pull/9748) > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:22:01 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 6 Mar 2017 11:22:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8228: ----------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/141 (was: https://github.com/wildfly/wildfly/pull/9748, https://github.com/wildfly-security-incubator/wildfly/pull/141) > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:24:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 6 Mar 2017 11:24:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8301) Picketlink trust domain config needs to be in attribute and not path In-Reply-To: References: Message-ID: Tomaz Cerar created WFLY-8301: --------------------------------- Summary: Picketlink trust domain config needs to be in attribute and not path Key: WFLY-8301 URL: https://issues.jboss.org/browse/WFLY-8301 Project: WildFly Issue Type: Bug Components: Security Reporter: Tomaz Cerar Assignee: Darran Lofthouse Currently trustdomain for PL federation is configured by adding new sub resource under idenity-provider Problem is that name of the trust domain resource you add is an url. In case that URL is ipv6 one in square brackets [::1] this makes it a invalid path. Currently testsuite relies on this to work, and by some miracle it works when configured via XML, but trying to do so with CLI fails as [] are forbidden chars in path (resource name) example of CLI command {{/subsystem=picketlink-federation/federation=federation-simple-redirect-binding/identity-provider=idp-redirect.war/trust-domain=${public.ip}:add /subsystem=picketlink-federation/federation=federation-redirect-with-signatures/identity-provider=idp-redirect-sig.war/trust-domain=${public.ip}:add /subsystem=picketlink-federation/federation=federation-simple-post-binding/identity-provider=idp-post.war/trust-domain=${public.ip}:add /subsystem=picketlink-federation/federation=federation-post-with-signatures/identity-provider=idp-post-sig.war/trust-domain=${public.ip}:add /subsystem=picketlink-federation/federation=federation-with-metadata/identity-provider=idp-metadata.war/trust-domain=${public.ip}:add}} where ${public.ip} can be 127.0.01 or [::1] I think given that TrustDomainResourceDefinition has no attributes beyond own name. it could be converted to a List on parent resource. or name should be used only for id, with additional attribute that would represent domain. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:25:01 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Mon, 6 Mar 2017 11:25:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-1227: ----------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Drools cannot be configured to expire Events properly > ----------------------------------------------------- > > Key: DROOLS-1227 > URL: https://issues.jboss.org/browse/DROOLS-1227 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Final > Environment: Windows, Java SE 1.8 > Reporter: Cristobal Arellano > Assignee: Mario Fusco > Priority: Critical > Attachments: expire_without_temporal_constraint.drl > > > Hello, > I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios: > ==SCENARIO A== > I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR? > * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK! > To solve this situation a tried the following scenario: > == SCENARIO B== > I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > @expires(0s) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * ExampleRule1 is triggered and event removed. OK! > * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR? > I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586). > Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:26:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 11:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-992) An SSLContext is not required to support a session context. In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-992: ------------------------------------ Summary: An SSLContext is not required to support a session context. Key: ELY-992 URL: https://issues.jboss.org/browse/ELY-992 Project: WildFly Elytron Issue Type: Bug Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta30 Otherwise if we use an SSLContext that does not support it we get a NPE, e.g. with wildfly-openssl: - {quote}Caused by: java.lang.NullPointerException at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:302) at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) at org.wildfly.extension.elytron.SSLDefinitions$4.lambda$getValueSupplier$1(SSLDefinitions.java:725) at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) ... 3 more {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:27:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 6 Mar 2017 11:27:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8300) standalone-picketlink.xml boots with lots of errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373432#comment-13373432 ] Brian Stansberry commented on WFLY-8300: ---------------------------------------- TBH I don't know that this config was ever meant to boot. I don't think it was; it has always included content that points to unavailable things. It was written as a form of documentation, not as an actually bootable config. > standalone-picketlink.xml boots with lots of errors > --------------------------------------------------- > > Key: WFLY-8300 > URL: https://issues.jboss.org/browse/WFLY-8300 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > If you try to run standalone-picketlink.xml server configuration, it's boot fails with lots of problems. They look related to elytron changes, but I am not sure. > {noformat} > 15:27:36,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "picketlink-identity-management"), > ("partition-manager" => "jpa.emf.modules.partition.manager") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store" => "org.jboss.msc.service.StartException in service jb > oss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store: Failed to start service > Caused by: org.picketlink.idm.config.SecurityConfigurationException: WFLYPL0050: Entities module not found [my.module]."}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store"] > } > 15:27:36,477 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory. > application-http-authentication]"] > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 11:55:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 6 Mar 2017 11:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8276) Upgrade JBeret from 1.2.2.Final to 1.2.3.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFLY-8276: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9749 > Upgrade JBeret from 1.2.2.Final to 1.2.3.Final > ---------------------------------------------- > > Key: WFLY-8276 > URL: https://issues.jboss.org/browse/WFLY-8276 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > Once JBeret 1.2.3.Final is released and upgrade of the component should be done. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 12:09:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Mon, 6 Mar 2017 12:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco closed DROOLS-1227. ------------------------------- Resolution: Rejected The engine is working as expected: an event can either have an explicit expiration configured on the event's class or an implicit one calculated on the length of the longest window used on that event. When both these criteria are missing the event has no automatic expiration at all and remains in the engine indefinitely unless it is programmatically retracted. > Drools cannot be configured to expire Events properly > ----------------------------------------------------- > > Key: DROOLS-1227 > URL: https://issues.jboss.org/browse/DROOLS-1227 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Final > Environment: Windows, Java SE 1.8 > Reporter: Cristobal Arellano > Assignee: Mario Fusco > Priority: Critical > Attachments: expire_without_temporal_constraint.drl > > > Hello, > I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios: > ==SCENARIO A== > I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR? > * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK! > To solve this situation a tried the following scenario: > == SCENARIO B== > I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > @expires(0s) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * ExampleRule1 is triggered and event removed. OK! > * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR? > I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586). > Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 12:13:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 12:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5128) TimeoutException: Could not acquire lock: Waiting to complete tx In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar resolved WFLY-5128. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 (was: 10.0.0.CR3) Resolution: Done > TimeoutException: Could not acquire lock: Waiting to complete tx > ---------------------------------------------------------------- > > Key: WFLY-5128 > URL: https://issues.jboss.org/browse/WFLY-5128 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1, 10.0.0.CR2 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Seen in these scenarios: > ejbservlet - shutdown/undeploy > http session - shutdown/undeploy > Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application. > Approx. 30 seconds after failing one node, one or more nodes intermittently log this error: > {code} > [JBossINF] 16:32:07,395 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (transport-thread--p7-t21) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on la5hJBZTPNMkBJCXILk9IzqA36rlEU-rSIUIwB-x on behalf of transaction GlobalTransaction::3179:local. Waiting to complete tx: RemoteTransaction{modifications=[], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=[la5hJBZTPNMkBJCXILk9IzqA36rlEU-rSIUIwB-x, la5hJBZTPNMkBJCXILk9IzqA36rlEU-rSIUIwB-x], lookedUpEntriesTopology=2147483647, isMarkedForRollback=false, tx=GlobalTransaction::31071:remote, state=null}. > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.newTimeoutException(AbstractTxLockingInterceptor.java:217) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.waitForTransactionsToComplete(AbstractTxLockingInterceptor.java:209) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:173) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:68) > [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:287) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:259) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:360) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:345) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103) > [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430) > [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427) > [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.schedule(InfinispanSessionManager.java:384) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.dataRehashed(InfinispanSessionManager.java:369) > [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497) > [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286) > [JBossINF] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) > [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1170) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1135) > [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyDataRehashed(CacheNotifierImpl.java:576) > [JBossINF] at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:385) > [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:200) > [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:47) > [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:115) > [JBossINF] at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:282) > [JBossINF] at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:217) > [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [JBossINF] at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173) > [JBossINF] at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > This error may be the root cause of https://issues.jboss.org/browse/JBEAP-505 (server ends up with Operation ("deploy") failed when restarted after failover). > The following error (and matching warning), occurring just before the above mentioned TimeoutException, is most likely also related: > {code} > [JBossINF] 16:31:56,503 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p3-t41) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key perf21 and requestor GlobalTransaction::78599:remote. Lock is held by GlobalTransaction::78433:remote, while request came from perf21 > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198) > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:185) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:118) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:200) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:141) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:199) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:196) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:99) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:76) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:129) > [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:85) > [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] 16:31:56,504 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderPerCacheInboundInvocationHandler] (remote-thread--p3-t41) ISPN000071: Caught exception when handling command LockControlCommand{cache=dist, keys=[perf21], flags=[IGNORE_RETURN_VALUES], unlock=false, gtx=GlobalTransaction::78599:remote}: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key perf21 and requestor GlobalTransaction::78599:remote. Lock is held by GlobalTransaction::78433:remote, while request came from perf21 > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198) > [JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:185) > [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:118) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:200) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:141) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:199) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:196) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:99) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:76) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:129) > [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:85) > [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > Server log: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-session-shutdown-dist-sync/4/console-perf19/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 12:33:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 12:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-993) SSLUtils.createSslContextFactory should support fail over to another Provider. In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-993: ------------------------------------ Summary: SSLUtils.createSslContextFactory should support fail over to another Provider. Key: ELY-993 URL: https://issues.jboss.org/browse/ELY-993 Project: WildFly Elytron Issue Type: Enhancement Components: SSL Affects Versions: 1.1.0.Beta28 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta29 The default SSLContext.getInstance() behaviour will automatically fail over to subsequent Providers if the selected Provider can not create the instance. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 12:35:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 12:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8303) Clustering testsuite: Remove XSLTs in favor of executing CLI scripts via wildfly-maven-plugin In-Reply-To: References: Message-ID: Radoslav Husar created WFLY-8303: ------------------------------------ Summary: Clustering testsuite: Remove XSLTs in favor of executing CLI scripts via wildfly-maven-plugin Key: WFLY-8303 URL: https://issues.jboss.org/browse/WFLY-8303 Project: WildFly Issue Type: Task Components: Clustering, Test Suite Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar i.e. {code:xml} org.wildfly.plugins wildfly-maven-plugin ${version.org.wildfly.plugin} process-test-resources execute-commands true ${wildfly.dir} ${project.build.directory}/wildfly-plugin.log ${node0} ${node0} ... {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 12:51:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Mon, 6 Mar 2017 12:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1463) DMN error message consolidation In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1463: -------------------------------------- Summary: DMN error message consolidation Key: DROOLS-1463 URL: https://issues.jboss.org/browse/DROOLS-1463 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari ..similarly to what available on dmn-feel -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 13:16:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 13:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration if first. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Summary: Ensure OpenSSL Registration if first. (was: Integrate OpenSSL Provider registration with Elytron) > Ensure OpenSSL Registration if first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > We need to remove the following block from SecurityRealmResourceDefinition: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > Registration will then be possible within the Elytron subsystem configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 13:17:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 13:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration if first. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Description: The following in SecurityRealmResourceDefinition registers the provider: - {code} static { //register the Openssl Provider, if possible //not really sure if this is the best place for it try { OpenSSLProvider.register(); DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); } catch (Throwable t){ DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); } } {code} It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. was: We need to remove the following block from SecurityRealmResourceDefinition: - {code} static { //register the Openssl Provider, if possible //not really sure if this is the best place for it try { OpenSSLProvider.register(); DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); } catch (Throwable t){ DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); } } {code} Registration will then be possible within the Elytron subsystem configuration. > Ensure OpenSSL Registration if first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The following in SecurityRealmResourceDefinition registers the provider: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 13:52:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 13:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration if first. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373520#comment-13373520 ] Darran Lofthouse commented on WFCORE-1802: ------------------------------------------ [~swd847] I am trying to ensure wildfly-openssl is registered first so we can use it if available and fallback if not: - https://github.com/darranl/wildfly-core/tree/WFCORE-1802 However I am running into a NPE within the 'org.jboss.as.test.integration.auditlog.AuditLogToTLSSyslogTestCase' test case. {{Caused by: java.lang.NullPointerException at org.wildfly.openssl.OpenSSLSocket.connect(OpenSSLSocket.java:547) at java.net.Socket.(Socket.java:434) at java.net.Socket.(Socket.java:244) at javax.net.ssl.SSLSocket.(SSLSocket.java:196) at org.wildfly.openssl.OpenSSLSocket.(OpenSSLSocket.java:83) at org.wildfly.openssl.OpenSSLContextSPI$1.createSocket(OpenSSLContextSPI.java:359) at org.jboss.as.controller.audit.SyslogAuditLogHandler$SSLContextOutputStream.(SyslogAuditLogHandler.java:480) at org.jboss.as.controller.audit.SyslogAuditLogHandler.initialize(SyslogAuditLogHandler.java:273) ... 31 more}} > Ensure OpenSSL Registration if first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The following in SecurityRealmResourceDefinition registers the provider: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 13:52:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 6 Mar 2017 13:52:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration if first. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373520#comment-13373520 ] Darran Lofthouse edited comment on WFCORE-1802 at 3/6/17 1:51 PM: ------------------------------------------------------------------ [~swd847] I am trying to ensure wildfly-openssl is registered first so we can use it if available and fallback if not: - https://github.com/darranl/wildfly-core/tree/WFCORE-1802 However I am running into a NPE within the 'org.jboss.as.test.integration.auditlog.AuditLogToTLSSyslogTestCase' test case. {{ Caused by: java.lang.NullPointerException at org.wildfly.openssl.OpenSSLSocket.connect(OpenSSLSocket.java:547) at java.net.Socket.(Socket.java:434) at java.net.Socket.(Socket.java:244) at javax.net.ssl.SSLSocket.(SSLSocket.java:196) at org.wildfly.openssl.OpenSSLSocket.(OpenSSLSocket.java:83) at org.wildfly.openssl.OpenSSLContextSPI$1.createSocket(OpenSSLContextSPI.java:359) at org.jboss.as.controller.audit.SyslogAuditLogHandler$SSLContextOutputStream.(SyslogAuditLogHandler.java:480) at org.jboss.as.controller.audit.SyslogAuditLogHandler.initialize(SyslogAuditLogHandler.java:273) ... 31 more }} was (Author: dlofthouse): [~swd847] I am trying to ensure wildfly-openssl is registered first so we can use it if available and fallback if not: - https://github.com/darranl/wildfly-core/tree/WFCORE-1802 However I am running into a NPE within the 'org.jboss.as.test.integration.auditlog.AuditLogToTLSSyslogTestCase' test case. {{Caused by: java.lang.NullPointerException at org.wildfly.openssl.OpenSSLSocket.connect(OpenSSLSocket.java:547) at java.net.Socket.(Socket.java:434) at java.net.Socket.(Socket.java:244) at javax.net.ssl.SSLSocket.(SSLSocket.java:196) at org.wildfly.openssl.OpenSSLSocket.(OpenSSLSocket.java:83) at org.wildfly.openssl.OpenSSLContextSPI$1.createSocket(OpenSSLContextSPI.java:359) at org.jboss.as.controller.audit.SyslogAuditLogHandler$SSLContextOutputStream.(SyslogAuditLogHandler.java:480) at org.jboss.as.controller.audit.SyslogAuditLogHandler.initialize(SyslogAuditLogHandler.java:273) ... 31 more}} > Ensure OpenSSL Registration if first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The following in SecurityRealmResourceDefinition registers the provider: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:22:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) Max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved UNDERTOW-983 to WFLY-8304: ----------------------------------------------- Project: WildFly (was: Undertow) Key: WFLY-8304 (was: UNDERTOW-983) Affects Version/s: 10.1.0.Final (was: 1.4.8.Final) > Max-attempts minimal value > -------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Labels: mod_cluster > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:22:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) Max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373562#comment-13373562 ] Radoslav Husar commented on WFLY-8304: -------------------------------------- This is a WFLY problem, not UNDERTOW one. > Max-attempts minimal value > -------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Labels: mod_cluster > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:22:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) Max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373562#comment-13373562 ] Radoslav Husar edited comment on WFLY-8304 at 3/6/17 3:21 PM: -------------------------------------------------------------- This is a WFLY problem, not UNDERTOW one; moved. was (Author: rhusar): This is a WFLY problem, not UNDERTOW one. > Max-attempts minimal value > -------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Labels: mod_cluster > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:23:00 2017 From: issues at jboss.org (R Searls (JIRA)) Date: Mon, 6 Mar 2017 15:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8305) Exclude org.ow2.asm:asm from bld. In-Reply-To: References: Message-ID: R Searls created WFLY-8305: ------------------------------ Summary: Exclude org.ow2.asm:asm from bld. Key: WFLY-8305 URL: https://issues.jboss.org/browse/WFLY-8305 Project: WildFly Issue Type: Task Components: Web Services Affects Versions: 11.0.0.Alpha1 Reporter: R Searls Assignee: R Searls Priority: Minor With the update to woodstox to 5.x archive org.ow2.asm is obsolete but is still pulled in. Add excludes as needed in the pom's to remove. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:24:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) Max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8304: --------------------------------- Priority: Minor (was: Major) > Max-attempts minimal value > -------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Priority: Minor > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:24:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) Max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8304: --------------------------------- Labels: (was: mod_cluster) > Max-attempts minimal value > -------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Priority: Minor > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:24:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) Max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8304: --------------------------------- Component/s: mod_cluster > Max-attempts minimal value > -------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Priority: Minor > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 15:25:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 15:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8304) mod_cluster max-attempts minimal value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8304: --------------------------------- Summary: mod_cluster max-attempts minimal value (was: Max-attempts minimal value) > mod_cluster max-attempts minimal value > -------------------------------------- > > Key: WFLY-8304 > URL: https://issues.jboss.org/browse/WFLY-8304 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.1.0.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > Priority: Minor > > [Documentation|http://modcluster.io/documentation/#proxy-configuration-1] > {noformat} > Maximum number of failover attempts before giving up. The minimum value is 0, i.e. no failover. The default value is 1, i.e. do a one failover attempt. > {noformat} > Max-attemps minimal value is > {noformat} > "max-attempts" => { > "type" => INT, > "description" => "Max attempts to process an idempotent request.", > "expressions-allowed" => true, > "nillable" => true, > "default" => 1, > "min" => -1L, > "max" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {noformat} > Min value to 0. In the mod_cluster subsystem(worker side). > And max-attemps handling on the balancer side. Balancer has minimal value of 1 and therefore any value lower than that is ignored. Should be 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 16:19:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 6 Mar 2017 16:19:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8291) mod_cluster operation descriptions only refer to Apache httpd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8291: --------------------------------- Summary: mod_cluster operation descriptions only refer to Apache httpd (was: Mod_cluster operation descriptions only refer to Apache httpd) > mod_cluster operation descriptions only refer to Apache httpd > ------------------------------------------------------------- > > Key: WFLY-8291 > URL: https://issues.jboss.org/browse/WFLY-8291 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Please repair description in following operations as they are outdated, undertow proxy > is able to process this messages. > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "disable", > "description" => "Tell Apache httpd that all contexts of the node can't process new requests.", > "request-properties" => {}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "disable-context", > "description" => "Tell Apache httpd that the context can't process new requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "enable", > "description" => "Tell Apache httpd that all contexts of the node are ready receive requests.", > "request-properties" => {}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "enable-context", > "description" => "Tell Apache httpd that the context is ready receive requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "Virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "Context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "stop", > "description" => "Tell Apache httpd that all contexts of the node can't process requests.", > "request-properties" => {"waittime" => { > "type" => INT, > "description" => "wait timeout", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => 10, > "unit" => "SECONDS" > }}, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} > {noformat} > { > "outcome" => "success", > "result" => { > "operation-name" => "stop-context", > "description" => "Tell Apache httpd that the context can't process requests.", > "request-properties" => { > "virtualhost" => { > "type" => STRING, > "description" => "Virtual host", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "context" => { > "type" => STRING, > "description" => "Context", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "waittime" => { > "type" => INT, > "description" => "wait timeout", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => 10, > "unit" => "SECONDS" > } > }, > "reply-properties" => {}, > "read-only" => false, > "runtime-only" => true > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 16:51:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 6 Mar 2017 16:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8303) Clustering testsuite: Remove XSLTs in favor of executing CLI scripts via wildfly-maven-plugin In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-8303: ------------------------------ Description: i.e. {code:xml} org.wildfly.plugins wildfly-maven-plugin ${version.org.wildfly.plugin} process-test-resources execute-commands true ${wildfly.dir} ${project.build.directory}/wildfly-plugin.log ${node0} ${node0} ... {code} was: i.e. {code:xml} org.wildfly.plugins wildfly-maven-plugin ${version.org.wildfly.plugin} process-test-resources execute-commands true ${wildfly.dir} ${project.build.directory}/wildfly-plugin.log ${node0} ${node0} ... {code} > Clustering testsuite: Remove XSLTs in favor of executing CLI scripts via wildfly-maven-plugin > --------------------------------------------------------------------------------------------- > > Key: WFLY-8303 > URL: https://issues.jboss.org/browse/WFLY-8303 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > i.e. > {code:xml} > > org.wildfly.plugins > wildfly-maven-plugin > ${version.org.wildfly.plugin} > > > process-test-resources > > execute-commands > > > > > true > > > > > > ${wildfly.dir} > ${project.build.directory}/wildfly-plugin.log > > ${node0} > ${node0} > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 17:22:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 6 Mar 2017 17:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1464) Unary tests raising NPE on null input In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1464: ------------------------------------- Summary: Unary tests raising NPE on null input Key: DROOLS-1464 URL: https://issues.jboss.org/browse/DROOLS-1464 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta6 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final Some unary tests are raising NPE on null input. E.g.: ```UnaryTestNode{ < 0 }``` -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 18:52:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 6 Mar 2017 18:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8300) standalone-picketlink.xml boots with lots of errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373616#comment-13373616 ] Brian Stansberry commented on WFLY-8300: ---------------------------------------- Sure; I was unclear. I don't mean not to do anything at all about this. I'm just pointing at that IIRC the config was never directly bootable so people looking at this shouldn't get confused and go off "fixing" stuff that was never meant to work. I assume the testsuite was doing something to alter the config before trying to use it. > standalone-picketlink.xml boots with lots of errors > --------------------------------------------------- > > Key: WFLY-8300 > URL: https://issues.jboss.org/browse/WFLY-8300 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > If you try to run standalone-picketlink.xml server configuration, it's boot fails with lots of problems. They look related to elytron changes, but I am not sure. > {noformat} > 15:27:36,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "picketlink-identity-management"), > ("partition-manager" => "jpa.emf.modules.partition.manager") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store" => "org.jboss.msc.service.StartException in service jb > oss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store: Failed to start service > Caused by: org.picketlink.idm.config.SecurityConfigurationException: WFLYPL0050: Entities module not found [my.module]."}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store"] > } > 15:27:36,477 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory. > application-http-authentication]"] > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 18:55:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 6 Mar 2017 18:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1465) FEEL grammar does not accept not() as an element in a list of unit tests In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1465: ------------------------------------- Summary: FEEL grammar does not accept not() as an element in a list of unit tests Key: DROOLS-1465 URL: https://issues.jboss.org/browse/DROOLS-1465 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta6 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final Grammar rule #17 prevents not() from being used as part of a unary test list. Needs to be fixed in the engine. Also, there seems to be a bug on the creation of not() unary tests as it is short-circuiting in some cases without checking all the elements. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 19:07:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 6 Mar 2017 19:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8300) standalone-picketlink.xml boots with lots of errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373619#comment-13373619 ] Tomaz Cerar commented on WFLY-8300: ----------------------------------- Sadly testsuite doesn't alter it that much at all. It is actually testing it that it works. Alteration that are done are only related ipv4 --> ipv6 changes to make it work in both scenarios. In a way the example picketlink config is more of testsuite config than any thing else. Also bit bad one at it, as it doesn't test some scenarios that would definitely fail as it doesn't boot all services right. > standalone-picketlink.xml boots with lots of errors > --------------------------------------------------- > > Key: WFLY-8300 > URL: https://issues.jboss.org/browse/WFLY-8300 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > If you try to run standalone-picketlink.xml server configuration, it's boot fails with lots of problems. They look related to elytron changes, but I am not sure. > {noformat} > 15:27:36,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "picketlink-identity-management"), > ("partition-manager" => "jpa.emf.modules.partition.manager") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store" => "org.jboss.msc.service.StartException in service jb > oss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store: Failed to start service > Caused by: org.picketlink.idm.config.SecurityConfigurationException: WFLYPL0050: Entities module not found [my.module]."}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store"] > } > 15:27:36,477 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory. > application-http-authentication]"] > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 20:11:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 6 Mar 2017 20:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1465) not() unary test is short circuiting in the presence of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1465: ---------------------------------- Summary: not() unary test is short circuiting in the presence of null (was: FEEL grammar does not accept not() as an element in a list of unit tests) > not() unary test is short circuiting in the presence of null > ------------------------------------------------------------ > > Key: DROOLS-1465 > URL: https://issues.jboss.org/browse/DROOLS-1465 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Beta6 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > Grammar rule #17 prevents not() from being used as part of a unary test list. Needs to be fixed in the engine. > Also, there seems to be a bug on the creation of not() unary tests as it is short-circuiting in some cases without checking all the elements. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 20:12:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 6 Mar 2017 20:12:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1465) not() unary test is short circuiting in the presence of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1465: ---------------------------------- Description: not() unary tests as it is short-circuiting in some cases without checking all the elements. E.g.: 10 in ( not( null, 10 ) ) ----> short circuits and returns true when it should be false null in ( not( 10, null ) ) -----> short circuits and returns true when it should be false was: Grammar rule #17 prevents not() from being used as part of a unary test list. Needs to be fixed in the engine. Also, there seems to be a bug on the creation of not() unary tests as it is short-circuiting in some cases without checking all the elements. > not() unary test is short circuiting in the presence of null > ------------------------------------------------------------ > > Key: DROOLS-1465 > URL: https://issues.jboss.org/browse/DROOLS-1465 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Beta6 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > not() unary tests as it is short-circuiting in some cases without checking all the elements. E.g.: > 10 in ( not( null, 10 ) ) ----> short circuits and returns true when it should be false > null in ( not( 10, null ) ) -----> short circuits and returns true when it should be false -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 00:13:00 2017 From: issues at jboss.org (Saurabh Sharma (JIRA)) Date: Tue, 7 Mar 2017 00:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1466) Bound fields when changed in the WHEN condition become uneditable after saving In-Reply-To: References: Message-ID: Saurabh Sharma created DROOLS-1466: -------------------------------------- Summary: Bound fields when changed in the WHEN condition become uneditable after saving Key: DROOLS-1466 URL: https://issues.jboss.org/browse/DROOLS-1466 Project: Drools Issue Type: Bug Components: tools Affects Versions: 6.4.0.Final Environment: IBM WebSphere Application Server Network Deployment 8.5.5.9 (64-bit) Reporter: Saurabh Sharma Assignee: Mario Fusco Priority: Minor Attachments: SimpleRule.jpg, SimpleRuleEdit.jpg Calculation of a mid price of an instrument While defining the WHEN condition, when a new price (NEWPRC) is bound from GSO.newPrice The required fields for that price is bound so that they can be changed in the THEN condition. The properties of the price are similar to any of the Bid or the Ask price except the unit price value. Those values are bound as well in the rule WHEN condition, and used in the THEN clause. In the THEN condition, the individual bound variables are set with values, the UI lets me add those values correctly without any issues the first time around. The problem occurs when the rule is saved, and opened again for editing. All the fields become uneditable and i have to repeat the steps of binding the variables of NEWPRC and then modify/set the values of those variables again in the WHEN condition. Is there any way to open the rule and get those bound variables in the edit mode -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 00:16:00 2017 From: issues at jboss.org (Saurabh Sharma (JIRA)) Date: Tue, 7 Mar 2017 00:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1467) Bound variables become uneditable once they are saved in the rule In-Reply-To: References: Message-ID: Saurabh Sharma created DROOLS-1467: -------------------------------------- Summary: Bound variables become uneditable once they are saved in the rule Key: DROOLS-1467 URL: https://issues.jboss.org/browse/DROOLS-1467 Project: Drools Issue Type: Bug Components: tools Affects Versions: 6.4.0.Final Environment: IBM WebSphere Application Server Network Deployment 8.5.5.9 (64-bit) Reporter: Saurabh Sharma Assignee: Mario Fusco Attachments: SimpleRule.jpg, SimpleRuleEdit.jpg Calculation of a mid price of an instrument While defining the WHEN condition, when a new price (NEWPRC) is bound from GSO.newPrice The required fields for that price is bound so that they can be changed in the THEN condition. The properties of the price are similar to any of the Bid or the Ask price except the unit price value. Those values are bound as well in the rule WHEN condition, and used in the THEN clause. In the THEN condition, the individual bound variables are set with values, the UI lets me add those values correctly without any issues the first time around. The problem occurs when the rule is saved, and opened again for editing. All the fields become uneditable and i have to repeat the steps of binding the variables of NEWPRC and then modify/set the values of those variables again in the WHEN condition. Is there any way to open the rule and get those bound variables in the edit mode -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 00:18:00 2017 From: issues at jboss.org (Saurabh Sharma (JIRA)) Date: Tue, 7 Mar 2017 00:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1467) Bound variables become uneditable once they are saved in the rule In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurabh Sharma closed DROOLS-1467. ---------------------------------- Resolution: Duplicate Issue DroolsDROOLS-1466 already raised > Bound variables become uneditable once they are saved in the rule > ----------------------------------------------------------------- > > Key: DROOLS-1467 > URL: https://issues.jboss.org/browse/DROOLS-1467 > Project: Drools > Issue Type: Bug > Components: tools > Affects Versions: 6.4.0.Final > Environment: IBM WebSphere Application Server Network > Deployment 8.5.5.9 (64-bit) > Reporter: Saurabh Sharma > Assignee: Mario Fusco > Attachments: SimpleRule.jpg, SimpleRuleEdit.jpg > > > Calculation of a mid price of an instrument > While defining the WHEN condition, when a new price (NEWPRC) is bound from GSO.newPrice > The required fields for that price is bound so that they can be changed in the THEN condition. > The properties of the price are similar to any of the Bid or the Ask price except the unit price value. Those values are bound as well in the rule WHEN condition, and used in the > THEN clause. > In the THEN condition, the individual bound variables are set with values, the UI lets me add those values correctly without any issues the first time around. > The problem occurs when the rule is saved, and opened again for editing. All the fields become uneditable and i have to repeat the steps of binding the variables of > NEWPRC and then modify/set the values of those variables again in the WHEN condition. > Is there any way to open the rule and get those bound variables in the edit mode -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 00:38:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Mar 2017 00:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373666#comment-13373666 ] RH Bugzilla Integration commented on WFCORE-2348: ------------------------------------------------- Radovan STANCEL changed the Status of [bug 1425754|https://bugzilla.redhat.com/show_bug.cgi?id=1425754] from ASSIGNED to POST > Error while starting WildFly as service in domain mode using init scripts. > -------------------------------------------------------------------------- > > Key: WFCORE-2348 > URL: https://issues.jboss.org/browse/WFCORE-2348 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta7 > Environment: Fedora, RHEL > Reporter: Radovan Stancel > Assignee: Radovan Stancel > Priority: Minor > Labels: downstream_dependency > Fix For: 3.0.0.Beta7 > > Original Estimate: 4 hours > Time Spent: 3 hours > Remaining Estimate: 1 hour > > When starting WildFly as a service in domain mode using init scripts there appears in console.log error: > /usr/bin/dirname: unrecognized option '--domain-config=domain.xml' > Try '/usr/bin/dirname --help' for more information. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 01:01:00 2017 From: issues at jboss.org (Einat Peretz (JIRA)) Date: Tue, 7 Mar 2017 01:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: Einat Peretz created WFLY-8306: ---------------------------------- Summary: Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 Key: WFLY-8306 URL: https://issues.jboss.org/browse/WFLY-8306 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.1.0.Final Environment: Windows Reporter: Einat Peretz Assignee: Stuart Douglas Priority: Blocker Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 02:08:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 7 Mar 2017 02:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2362) Regression: Legacy LDAP security-realm reads system-property only during boot In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2362: ------------------------------------ Summary: Regression: Legacy LDAP security-realm reads system-property only during boot Key: WFCORE-2362 URL: https://issues.jboss.org/browse/WFCORE-2362 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Blocker In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Since EAP 7.1.0.DR12 it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature. This issue does not affects scenarios, where system property is set in standalone.conf. We request blocker flag due to regression. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 02:09:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 7 Mar 2017 02:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2362) Regression: Legacy LDAP security-realm reads system-property only during boot In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2362: --------------------------------- Description: In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Currently it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature. This issue does not affects scenarios, where system property is set in standalone.conf. was: In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Since EAP 7.1.0.DR12 it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature. This issue does not affects scenarios, where system property is set in standalone.conf. We request blocker flag due to regression. > Regression: Legacy LDAP security-realm reads system-property only during boot > ----------------------------------------------------------------------------- > > Key: WFCORE-2362 > URL: https://issues.jboss.org/browse/WFCORE-2362 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: print-roles.war > > > In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Currently it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature. > This issue does not affects scenarios, where system property is set in standalone.conf. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 02:09:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 7 Mar 2017 02:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2362) Regression: Legacy LDAP security-realm reads system-property only during boot In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2362: --------------------------------- Attachment: print-roles.war > Regression: Legacy LDAP security-realm reads system-property only during boot > ----------------------------------------------------------------------------- > > Key: WFCORE-2362 > URL: https://issues.jboss.org/browse/WFCORE-2362 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: print-roles.war > > > In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Currently it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature. > This issue does not affects scenarios, where system property is set in standalone.conf. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 03:47:03 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 7 Mar 2017 03:47:03 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8307) If name of database table is written in small letters Artemis can't detect its existence In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil moved JBEAP-9346 to WFLY-8307: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8307 (was: JBEAP-9346) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: (was: 7.1.0.DR13) > If name of database table is written in small letters Artemis can't detect its existence > ---------------------------------------------------------------------------------------- > > Key: WFLY-8307 > URL: https://issues.jboss.org/browse/WFLY-8307 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: Oracle 12c database > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Critical > > If the name of database table is written in small letters - e.g. node1_messages_table, Artemis can't detect its existence and it tries to create it again what leads to error \[1\]. This happens after restarting of server. > I don't see the issue if name of database table is written in capital letters - e.g. NODE1_MESSAGES_TABLE. > \[1\] > {code} > 14:00:26,208 ERROR [org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver] (ServerService Thread Pool -- 72) > SQL STATEMENTS: > CREATE TABLE node1_large_messages_table(ID NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY, FILENAME VARCHAR(255), EXTENSION VARCHAR(10), DATA BLOB, PRIMARY KEY(ID)) > SQL EXCEPTIONS: > SQLState: 42000 ErrorCode: 955 Message: ORA-00955: name is already used by an existing object > 14:00:26,372 ERROR [org.apache.activemq.artemis.journal] (ServerService Thread Pool -- 72) Could not start file factory, unable to connect to database: java.sql.SQLSyntaxErrorException: ORA-00955: name is already used by an existing objec > t > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) > at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) > at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) > at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) > at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) > at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) > at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) > at oracle.jdbc.driver.OracleStatement.executeUpdateInternal(OracleStatement.java:1707) > at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:1670) > at oracle.jdbc.driver.OracleStatementWrapper.executeUpdate(OracleStatementWrapper.java:310) > at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430) > at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.createTableIfNotExists(AbstractJDBCDriver.java:170) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.createTable(AbstractJDBCDriver.java:99) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createSchema(JDBCSequentialFileFactoryDriver.java:66) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.start(AbstractJDBCDriver.java:71) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactory.start(JDBCSequentialFileFactory.java:91) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager.init(JDBCJournalStorageManager.java:74) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:216) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:104) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager.(JDBCJournalStorageManager.java:52) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:1860) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2000) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:62) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:520) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:469) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:412) [artemis-jms-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1] > at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-14.jar:7.1.0.Alpha1-redhat-14] > at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-14.jar:7.1.0.Alpha1-redhat-14] > at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-14.jar:7.1.0.Alpha1-redhat-14] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_121] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_121] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_121] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_121] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final-redhat-1.jar:2.2.1.Final-redhat-1] > {code} > *Customer impact:* If names of database tables are written in small letters, EAP fails at second start. From logs it's not easy to find out what is wrong and how workaround the issue. It is serious user experience problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 03:57:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Tue, 7 Mar 2017 03:57:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-36) IPV6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan updated HAWKULARQE-36: ------------------------------------- Description: See: [HAWKULAR-1193|https://issues.jboss.org/browse/HAWKULAR-1193] Create IPv6 testing environment and run smoke tests on it. Automate via jenkins job running CFME smoke tests. was:See: [HAWKULAR-1193|https://issues.jboss.org/browse/HAWKULAR-1193] > IPV6 > ---- > > Key: HAWKULARQE-36 > URL: https://issues.jboss.org/browse/HAWKULARQE-36 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > See: [HAWKULAR-1193|https://issues.jboss.org/browse/HAWKULAR-1193] > Create IPv6 testing environment and run smoke tests on it. > Automate via jenkins job running CFME smoke tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 04:04:00 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Tue, 7 Mar 2017 04:04:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1468) Support OOPath in accumulate functions In-Reply-To: References: Message-ID: Tibor Zim?nyi created DROOLS-1468: ------------------------------------- Summary: Support OOPath in accumulate functions Key: DROOLS-1468 URL: https://issues.jboss.org/browse/DROOLS-1468 Project: Drools Issue Type: Feature Request Components: core engine Affects Versions: 7.0.0.Beta7 Reporter: Tibor Zim?nyi Assignee: Mario Fusco Priority: Minor It would be nice to have the ability to use OOPath in accumulate functions. E.g. _sum(/fact/property)_. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 04:05:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Tue, 7 Mar 2017 04:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8308) Legacy ldap realm returns 401 if LDAP is unreachable In-Reply-To: References: Message-ID: Martin Choma created WFLY-8308: ---------------------------------- Summary: Legacy ldap realm returns 401 if LDAP is unreachable Key: WFLY-8308 URL: https://issues.jboss.org/browse/WFLY-8308 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Contradics JBEAP-8125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 04:08:01 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Tue, 7 Mar 2017 04:08:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1468) Support OOPath in accumulate functions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Zim?nyi updated DROOLS-1468: ---------------------------------- Description: It would be nice to have the ability to use OOPath in accumulate functions. E.g. _sum(/fact/property)_. Example of a rule: import org.drools.compiler.oopath.*; global java.lang.Object globalVar rule R when accumulate ( Adult() ; $accumulateResult: sum(/children/age) ) then kcontext.getKieRuntime().setGlobal(\"globalVar\", $accumulateResult); end was:It would be nice to have the ability to use OOPath in accumulate functions. E.g. _sum(/fact/property)_. > Support OOPath in accumulate functions > -------------------------------------- > > Key: DROOLS-1468 > URL: https://issues.jboss.org/browse/DROOLS-1468 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zim?nyi > Assignee: Mario Fusco > Priority: Minor > > It would be nice to have the ability to use OOPath in accumulate functions. E.g. _sum(/fact/property)_. > Example of a rule: > import org.drools.compiler.oopath.*; > global java.lang.Object globalVar > rule R when > accumulate ( Adult() ; $accumulateResult: sum(/children/age) ) > then > kcontext.getKieRuntime().setGlobal(\"globalVar\", $accumulateResult); > end -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 04:43:00 2017 From: issues at jboss.org (Peter Palaga (JIRA)) Date: Tue, 7 Mar 2017 04:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8175) mvnw wrapper shouldn't deppend on .m2/wrapper location In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Palaga reopened WFLY-8175: -------------------------------- Reopening because the downstream JBEAP-8923 was reopened too. > mvnw wrapper shouldn't deppend on .m2/wrapper location > ------------------------------------------------------ > > Key: WFLY-8175 > URL: https://issues.jboss.org/browse/WFLY-8175 > Project: WildFly > Issue Type: Bug > Components: Build System, Test Suite > Reporter: Peter Palaga > Assignee: Peter Palaga > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > mvnw stores maven to ~/.m2/wrapper directory. But customers could have denied access to .m2 folder. They could have allowed access only to .m2/repository, because they want to protect settings.xml file. > Our mvnw script should download maven to project directory. > Possible solution could be adding these two lines to .mvn/wrapper/maven-wrapper.properties: > {noformat} > distributionBase=PROJECT > zipStoreBase=PROJECT > {noformat} > This issue is regression against EAP 7.0.0 and EAP 7.1.0.DR11. > FYI: unfortunately, [distributionBase|https://github.com/takari/maven-wrapper/blob/master/src/main/java/org/apache/maven/wrapper/WrapperExecutor.java#L32] and [zipStoreBase|https://github.com/takari/maven-wrapper/blob/master/src/main/java/org/apache/maven/wrapper/WrapperExecutor.java#L34] properties are not documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:07:01 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 7 Mar 2017 05:07:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1469) Using ExternalSpreadsheetCompiler in osgi throws java.lang.ClassNotFoundException In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1469: ----------------------------------- Summary: Using ExternalSpreadsheetCompiler in osgi throws java.lang.ClassNotFoundException Key: DROOLS-1469 URL: https://issues.jboss.org/browse/DROOLS-1469 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco Trying to compile a rule template using ExternalSpreadsheetCompiler, the rule compilation works correctly in stand alone eclipse project, but when done inside an OSGI bundle the following exception is throw at runtime: {code} java.lang.ClassNotFoundException: Unable to find class 'org.drools.template.parser.DefaultGenerator' at org.drools.core.base.ClassTypeResolver.resolveType(ClassTypeResolver.java:241) at org.drools.core.base.ClassTypeResolver.resolveType(ClassTypeResolver.java:130) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.processGlobals(KnowledgeBuilderImpl.java:1640) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.processOtherDeclarations(KnowledgeBuilderImpl.java:1613) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.mergePackage(KnowledgeBuilderImpl.java:1605) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:980) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:365) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:341) at org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(DefaultTemplateRuleBase.java:133) at org.drools.template.parser.DefaultTemplateRuleBase.(DefaultTemplateRuleBase.java:56) at org.drools.template.parser.TemplateDataListener.(TemplateDataListener.java:74) at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:99) at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:85) at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.compileRules(DroolsBundleTracker.java:204) at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.addNewRulesFromContexts(DroolsBundleTracker.java:183) at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.addingBundle(DroolsBundleTracker.java:119) at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.addingBundle(DroolsBundleTracker.java:67) at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:07:01 2017 From: issues at jboss.org (Peter Palaga (JIRA)) Date: Tue, 7 Mar 2017 05:07:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8309) build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Palaga moved JBEAP-9348 to WFLY-8309: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8309 (was: JBEAP-9348) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System Test Suite (was: Build System) (was: Test Suite) Affects Version/s: (was: 7.1.0.DR12) Affects Testing: (was: Regression,Blocks Testing) > build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC > ----------------------------------------------------------------------- > > Key: WFLY-8309 > URL: https://issues.jboss.org/browse/WFLY-8309 > Project: WildFly > Issue Type: Bug > Components: Build System, Test Suite > Reporter: Peter Palaga > Assignee: Peter Palaga > Priority: Critical > > Solaris 10 SPARC and Solaris 11 SPARC are supported platforms. > This issue is regression against EAP 7.1.0.DR11. > *Wrong behaviour in EAP 7.1.0.DR12* > build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC. > *Desired behaviour* > build.sh and integration-tests.sh scripts should work on Solaris SPARC. > *Solaris 10* > * Solaris 10 SPARC release information: > {noformat} > [hudson at dev139-03 ~]$ cat /etc/release > Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. > Assembled 17 January 2013 > [hudson at dev139-03 ~]$ > {noformat} > * logs from build.sh > {noformat} > 07:39:36 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke > 07:39:36 ./build.sh: syntax error at line 20: `DIRNAME="$( cd "$' unexpected > {noformat} > * logs from integration-tests.sh: > {noformat} > 07:43:10 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1 > 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/tools/maven/conf/settings.xml > 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw: syntax error at line 190: `(' unexpected > {noformat} > *Solaris 11* > * Solaris 11 SPARC release information: > {noformat} > [hudson at dev34-03 ~]$ cat /etc/release > Oracle Solaris 11.3 SPARC > Copyright (c) 1983, 2016, Oracle and/or its affiliates. All rights reserved. > Assembled 03 August 2016 > [hudson at dev34-03 ~]$ > {noformat} > * logs from build.sh > {noformat} > 07:39:35 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke > 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw install '-Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository' '-fae' '-Dmaven.test.failure.ignore=true' '-Dts.noSmoke' > 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory] > 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory] > 07:39:36 Error: Could not find or load main class org.apache.maven.wrapper.MavenWrapperMain > {noformat} > * logs from integration-tests.sh: > {noformat} > 7:43:15 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1 > 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/tools/maven/conf/settings.xml > 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory] > 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory] > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:17:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 7 Mar 2017 05:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8310) Runtime handling for protocol-manager-factory is not implemented on "connection-factory" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil moved JBEAP-9349 to WFLY-8310: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8310 (was: JBEAP-9349) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) Affects Version/s: (was: 7.0.0.CR2) > Runtime handling for protocol-manager-factory is not implemented on "connection-factory" > ---------------------------------------------------------------------------------------- > > Key: WFLY-8310 > URL: https://issues.jboss.org/browse/WFLY-8310 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > When trying to update attribute _protocol-manager-factory_ of _/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory_ it raises the following exception > {code:java} > 17:36:06,807 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("connection-factory" => "RemoteConnectionFactory") > ]): java.lang.UnsupportedOperationException: WFLYMSGAMQ0053: Runtime handling for protocol-manager-factory is not implemented > at org.wildfly.extension.messaging.activemq.jms.ConnectionFactoryWriteAttributeHandler.applyOperationToActiveMQService(ConnectionFactoryWriteAttributeHandler.java:189) > at org.wildfly.extension.messaging.activemq.jms.ConnectionFactoryWriteAttributeHandler.applyUpdateToRuntime(ConnectionFactoryWriteAttributeHandler.java:96) > at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:52:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Tue, 7 Mar 2017 05:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-45) Setup Jenkins Slave server on openstack to run cf-ui smoke test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373853#comment-13373853 ] Sunil kondkar commented on HAWKULARQE-45: ----------------------------------------- able to connect via vnc using ip: vncviewer 10.8.184.19:6 > Setup Jenkins Slave server on openstack to run cf-ui smoke test suite > --------------------------------------------------------------------- > > Key: HAWKULARQE-45 > URL: https://issues.jboss.org/browse/HAWKULARQE-45 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > At present Jenkins slave is on BC and sometimes smoke test suites fai due to timeout issue. This task is to setup Jenkins slave on openstack instance. > Install: > Python > Chrome/FF > Headless Selenium > xvfb > connect via vnc -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 06:09:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Tue, 7 Mar 2017 06:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-45) Setup Jenkins Slave server on openstack to run cf-ui smoke test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar resolved HAWKULARQE-45. ------------------------------------- Resolution: Done > Setup Jenkins Slave server on openstack to run cf-ui smoke test suite > --------------------------------------------------------------------- > > Key: HAWKULARQE-45 > URL: https://issues.jboss.org/browse/HAWKULARQE-45 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > At present Jenkins slave is on BC and sometimes smoke test suites fai due to timeout issue. This task is to setup Jenkins slave on openstack instance. > Install: > Python > Chrome/FF > Headless Selenium > xvfb > connect via vnc -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 08:51:00 2017 From: issues at jboss.org (Jochen Welle (JIRA)) Date: Tue, 7 Mar 2017 08:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374022#comment-13374022 ] Jochen Welle commented on DROOLS-1227: -------------------------------------- Thanks for clarification. I think the documentation needs to be updated then. I could not figure out the expected behavior. In [9.8.2. Inferred expiration offset|https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html_single/#d0e12958] it states, that for both _BuyOrderEvent_ and _AckEvent_ an inferred expiration offset is computed. In my test _BuyOrderEvent_ is correctly removed after 10s but _AckEvent_ is not. I attached the test (again executed against Drools 6.5.0.Final). > Drools cannot be configured to expire Events properly > ----------------------------------------------------- > > Key: DROOLS-1227 > URL: https://issues.jboss.org/browse/DROOLS-1227 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Final > Environment: Windows, Java SE 1.8 > Reporter: Cristobal Arellano > Assignee: Mario Fusco > Priority: Critical > Attachments: expire_without_temporal_constraint.drl > > > Hello, > I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios: > ==SCENARIO A== > I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR? > * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK! > To solve this situation a tried the following scenario: > == SCENARIO B== > I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > @expires(0s) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * ExampleRule1 is triggered and event removed. OK! > * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR? > I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586). > Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 08:54:00 2017 From: issues at jboss.org (Jochen Welle (JIRA)) Date: Tue, 7 Mar 2017 08:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374025#comment-13374025 ] Jochen Welle commented on DROOLS-1227: -------------------------------------- Sorry, I cannot attach the test. Follows inline: {code:java} package testpackage; import static org.junit.Assert.assertEquals; import java.util.concurrent.TimeUnit; import org.drools.core.ClockType; import org.drools.core.time.SessionPseudoClock; import org.junit.Before; import org.junit.Test; import org.kie.api.KieBase; import org.kie.api.KieServices; import org.kie.api.builder.KieBuilder; import org.kie.api.builder.KieFileSystem; import org.kie.api.builder.Message; import org.kie.api.builder.model.KieBaseModel; import org.kie.api.builder.model.KieModuleModel; import org.kie.api.builder.model.KieSessionModel; import org.kie.api.conf.EventProcessingOption; import org.kie.api.definition.type.FactType; import org.kie.api.runtime.KieContainer; import org.kie.api.runtime.KieSession; import org.kie.api.runtime.conf.ClockTypeOption; public class ExpirationTest { KieContainer kieContainer; @Before public void setup() { KieServices kieServices = KieServices.Factory.get(); // create KieModule programmatically (instead of using kmodule.xml): KieModuleModel kieModuleModel = kieServices.newKieModuleModel(); KieBaseModel kieBaseModel1 = kieModuleModel.newKieBaseModel( "KBase1 ") .setDefault( true ) .setEventProcessingMode( EventProcessingOption.STREAM ); //.setEqualsBehavior( EqualityBehaviorOption.EQUALITY ) KieSessionModel ksessionModel1 = kieBaseModel1.newKieSessionModel( "KSession1" ) .setDefault( true ) .setType( KieSessionModel.KieSessionType.STATEFUL ) .setClockType( ClockTypeOption.get(ClockType.PSEUDO_CLOCK.toString()) ); // add KModuleXML to KieFileSystem: KieFileSystem kfs = kieServices.newKieFileSystem(); kfs.writeKModuleXML(kieModuleModel.toXML()); String str = "package testpackage\n" + "declare BuyOrderEvent\n" + "@role(event)\n" + " id : int\n" + "end\n" + "declare AckEvent\n" + "@role(event)\n" + " id : int\n" + "end\n" + "rule \"correlate orders\"\n" + "when\n" + " $bo : BuyOrderEvent( $id : id ) \n" + " $ae : AckEvent( id == $id, this after[0,10s] $bo )\n" + "then\n" + " System.out.println(\"buy and ack correlated\");\n" + "end\n"; kfs.write("src/main/resources/testpackage/testExpiration.drl", str); KieBuilder kieBuilder = kieServices.newKieBuilder( kfs ).buildAll(); // build KieModule and add it to the KieRepository (Singleton) assertEquals( 0, kieBuilder.getResults().getMessages( Message.Level.ERROR ).size() ); // If a release id is not defined (with KieFileSystem.writePomXML()) the default release id is used: assertEquals(kieServices.getRepository().getDefaultReleaseId(), kieBuilder.getKieModule().getReleaseId()); kieContainer = kieServices.newKieContainer(kieBuilder.getKieModule().getReleaseId()); } @Test public void testBuyAck() throws Exception { KieBase kieBase = kieContainer.getKieBase(); KieSession kieSession = kieContainer.newKieSession(); SessionPseudoClock clock = kieSession.getSessionClock(); FactType buyType = kieBase.getFactType("testpackage", "BuyOrderEvent"); FactType ackType = kieBase.getFactType("testpackage", "AckEvent"); Object buy = buyType.newInstance(); buyType.set(buy, "id", 1); Object ack = ackType.newInstance(); ackType.set(ack, "id", 1); kieSession.insert(buy); kieSession.insert(ack); assertEquals(2, kieSession.getFactCount()); // we have two facts inserted kieSession.fireAllRules(); clock.advanceTime(11, TimeUnit.SECONDS); kieSession.fireAllRules(); for (Object fh : kieSession.getFactHandles()) { System.out.println(fh.toString()); } // BuyOrderEvent is removed but AckEvent not, according to documentation both should be removed. assertEquals(0, kieSession.getFactCount()); kieSession.dispose(); } @Test public void testAcks() throws Exception { KieBase kieBase = kieContainer.getKieBase(); KieSession kieSession = kieContainer.newKieSession(); SessionPseudoClock clock = kieSession.getSessionClock(); FactType ackType = kieBase.getFactType("testpackage", "AckEvent"); Object ack = ackType.newInstance(); ackType.set(ack, "id", 42); kieSession.insert(ack); clock.advanceTime(1, TimeUnit.MILLISECONDS); kieSession.fireAllRules(); for (Object fh : kieSession.getFactHandles()) { System.out.println(fh.toString()); } clock.advanceTime(11, TimeUnit.SECONDS); kieSession.fireAllRules(); for (Object fh : kieSession.getFactHandles()) { System.out.println(fh.toString()); } assertEquals(0, kieSession.getFactCount()); kieSession.dispose(); } } {code} > Drools cannot be configured to expire Events properly > ----------------------------------------------------- > > Key: DROOLS-1227 > URL: https://issues.jboss.org/browse/DROOLS-1227 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Final > Environment: Windows, Java SE 1.8 > Reporter: Cristobal Arellano > Assignee: Mario Fusco > Priority: Critical > Attachments: expire_without_temporal_constraint.drl > > > Hello, > I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios: > ==SCENARIO A== > I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR? > * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK! > To solve this situation a tried the following scenario: > == SCENARIO B== > I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > @expires(0s) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * ExampleRule1 is triggered and event removed. OK! > * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR? > I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586). > Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 09:06:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 7 Mar 2017 09:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8311) ClassNotFoundException when ActiveMQRegistry is loaded by a JMS Bridge In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil moved JBEAP-9359 to WFLY-8311: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8311 (was: JBEAP-9359) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: (was: 7.1.0.DR13) > ClassNotFoundException when ActiveMQRegistry is loaded by a JMS Bridge > ---------------------------------------------------------------------- > > Key: WFLY-8311 > URL: https://issues.jboss.org/browse/WFLY-8311 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > When a JMS bridge is started with debug log, it shows the exception: > {code} > 2017-03-01 13:18:45,894 DEBUG [org.apache.activemq.artemis.jms.bridge] (ServerService Thread Pool -- 70) unable to load recovery registry org.jboss.as.messaging.jms.AS7RecoveryRegistry: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/service/extensions/xa/recovery/ActiveMQRegistry > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.locateRecoveryRegistry(JMSBridgeImpl.java:1885) > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:333) > at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService.startBridge(JMSBridgeService.java:105) > at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService$1.run(JMSBridgeService.java:76) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQRegistry from [Module "org.apache.activemq.artemis:main" from local module loader @7bfcd12c (finder: local module finder @42f30e0a (roots: /home/bershath/apps/jboss/7/jboss-eap-7.0/modules,/home/bershath/apps/jboss/7/jboss-eap-7.0/modules/system/layers/base/.overlays/layer-base-jboss-eap-7.0.4.CP,/home/bershath/apps/jboss/7/jboss-eap-7.0/modules/system/layers/base))] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > ... 8 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 09:30:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Tue, 7 Mar 2017 09:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8312) Unable to read-resource when application-security-domain is either defined or required In-Reply-To: References: Message-ID: Bartosz Baranowski created WFLY-8312: ---------------------------------------- Summary: Unable to read-resource when application-security-domain is either defined or required Key: WFLY-8312 URL: https://issues.jboss.org/browse/WFLY-8312 Project: WildFly Issue Type: Bug Reporter: Bartosz Baranowski Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 09:34:02 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 7 Mar 2017 09:34:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8313) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. In-Reply-To: References: Message-ID: Hynek ?v?bek created WFLY-8313: ---------------------------------- Summary: Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. Key: WFLY-8313 URL: https://issues.jboss.org/browse/WFLY-8313 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Priority: Critical Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError. I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError. You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 09:44:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 7 Mar 2017 09:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8313) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFLY-8313: ------------------------------- Steps to Reproduce: *Add user and group* ./bin/add-user.sh -u duke -p password1 -g JBossAdmin -a *Add new modules with custom implementation* ./bin/jboss-cli.sh {code} embed-server module add --name=org.jboss.custommodifiablerealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/custommodifiablerealmimpl.jar module add --name=org.jboss.customrealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmimpl.jar module add --name=org.jboss.customrealmmapperimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmmapperimpl.jar stop-embedded-server {code} *Deploy test application* Copy attached war file print-roles.war to JBOSS_HOME/standalone/deployments *Copy configuration files from attachment to your server* standalone-full.custommodifiablerealmimpl.xml, standalone-full.customrealmimpl.xml, standalone-full.customrealmmapperimpl.xml *Run server with given configuration - Elytron is set* {code} ./bin/standalone.sh -c=standalone-full.custommodifiablerealmimpl.xml {code} {code} ./bin/standalone.sh -c=standalone-full.customrealmimpl.xml {code} {code} ./bin/standalone.sh -c=standalone-full.customrealmmapperimpl.xml {code} *Invoke test app (if necessary)* http://127.0.0.1:8080/print-roles/protected/printRoles?role=JBossAdmin Now you can see error message about AbstractMethodError. For example: {code} java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomModifiableRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract {code} Whole stack trace {code:collapse=true} 2017-03-07 15:19:58,926 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract at org.wildfly.extras.creaper.commands.elytron.realm.AddCustomRealmImpl.getEvidenceVerifySupport(AddCustomRealmImpl.java) at org.wildfly.security.auth.server.SecurityDomain.lambda$getEvidenceVerifySupport$12(SecurityDomain.java:457) at org.wildfly.security.auth.server.SecurityDomain.getSupportLevel(SecurityDomain.java:484) at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:455) at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:473) at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.getMechanismNames(AbstractMechanismAuthenticationFactory.java:96) at org.wildfly.security.auth.server.HttpAuthenticationFactory.getMechanismNames(HttpAuthenticationFactory.java:50) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:461) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425) at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415) at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) ... 6 more 2017-03-07 15:19:58,931 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: { "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract"}, "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"] } {code} was: *Add user and group* ./bin/add-user.sh -u duke -p password1 -g JBossAdmin -a *Add new modules with custom implementation* ./bin/jboss-cli.sh {code} embed-server module add --name=org.jboss.custommodifiablerealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/custommodifiablerealmimpl.jar module add --name=org.jboss.customrealmimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmimpl.jar module add --name=org.jboss.customrealmmapperimpl --dependencies=org.wildfly.extension.elytron,org.wildfly.security.elytron --resources=/tmp/customrealmmapperimpl.jar stop-embedded-server {code} *Deploy test application* Copy attached war file print-roles.war to JBOSS_HOME/standalone/deployments *Run server with given configuration - Elytron is set* {code} ./bin/standalone.sh -c=standalone-full.custommodifiablerealmimpl.xml {code} {code} ./bin/standalone.sh -c=standalone-full.customrealmimpl.xml {code} {code} ./bin/standalone.sh -c=standalone-full.customrealmmapperimpl.xml {code} *Invoke test app (if necessary)* http://127.0.0.1:8080/print-roles/protected/printRoles?role=JBossAdmin Now you can see error message about AbstractMethodError. For example: {code} java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomModifiableRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract {code} Whole stack trace {code:collapse=true} 2017-03-07 15:19:58,926 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract at org.wildfly.extras.creaper.commands.elytron.realm.AddCustomRealmImpl.getEvidenceVerifySupport(AddCustomRealmImpl.java) at org.wildfly.security.auth.server.SecurityDomain.lambda$getEvidenceVerifySupport$12(SecurityDomain.java:457) at org.wildfly.security.auth.server.SecurityDomain.getSupportLevel(SecurityDomain.java:484) at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:455) at org.wildfly.security.auth.server.SecurityDomain.getEvidenceVerifySupport(SecurityDomain.java:473) at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.getMechanismNames(AbstractMechanismAuthenticationFactory.java:96) at org.wildfly.security.auth.server.HttpAuthenticationFactory.getMechanismNames(HttpAuthenticationFactory.java:50) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:461) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425) at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415) at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) ... 6 more 2017-03-07 15:19:58,931 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: { "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract Caused by: java.lang.AbstractMethodError: Method org/wildfly/extras/creaper/commands/elytron/realm/AddCustomRealmImpl.getEvidenceVerifySupport(Ljava/lang/Class;Ljava/lang/String;)Lorg/wildfly/security/auth/SupportLevel; is abstract"}, "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"] } {code} > Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8313 > URL: https://issues.jboss.org/browse/WFLY-8313 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Critical > > Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError. > I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError. > You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 10:00:01 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Tue, 7 Mar 2017 10:00:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374115#comment-13374115 ] Jean-Francois Denise commented on WFCORE-411: --------------------------------------------- The linked issue address all platforms. > Syntax error when applying patch and exiting jboss-cli > ------------------------------------------------------ > > Key: WFCORE-411 > URL: https://issues.jboss.org/browse/WFCORE-411 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Patching > Reporter: Arun Gupta > Assignee: Alexey Loubyansky > > [disconnected /] patch apply > ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch > { > "outcome" : "success", > "result" : {} > } > [disconnected /] > [disconnected /] > [disconnected /] > [disconnected /] exit > logging.configuration already set in JAVA_OPTS > ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi' > ./bin/jboss-cli.sh: line 81: `fi' -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 10:00:06 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Tue, 7 Mar 2017 10:00:06 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise closed WFCORE-411. --------------------------------------- Resolution: Duplicate Issue > Syntax error when applying patch and exiting jboss-cli > ------------------------------------------------------ > > Key: WFCORE-411 > URL: https://issues.jboss.org/browse/WFCORE-411 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Patching > Reporter: Arun Gupta > Assignee: Alexey Loubyansky > > [disconnected /] patch apply > ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch > { > "outcome" : "success", > "result" : {} > } > [disconnected /] > [disconnected /] > [disconnected /] > [disconnected /] exit > logging.configuration already set in JAVA_OPTS > ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi' > ./bin/jboss-cli.sh: line 81: `fi' -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 10:27:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Tue, 7 Mar 2017 10:27:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6198) When a datasource has no connection-properties and its driver has defined datasource-class a warning should be issued In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet closed WFLY-6198. ----------------------------------- > When a datasource has no connection-properties and its driver has defined datasource-class a warning should be issued > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6198 > URL: https://issues.jboss.org/browse/WFLY-6198 > Project: WildFly > Issue Type: Enhancement > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties. > Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class. > A warning when the datasource-class is defined but no connection-properties are present should be issued. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 10:35:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 7 Mar 2017 10:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1227) Drools cannot be configured to expire Events properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reopened DROOLS-1227: --------------------------------- Documentation is indeed correct and it seems that the current implementation is no longer following it. I'll further check this issue. Thanks for having clarified it. > Drools cannot be configured to expire Events properly > ----------------------------------------------------- > > Key: DROOLS-1227 > URL: https://issues.jboss.org/browse/DROOLS-1227 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Final > Environment: Windows, Java SE 1.8 > Reporter: Cristobal Arellano > Assignee: Mario Fusco > Priority: Critical > Attachments: expire_without_temporal_constraint.drl > > > Hello, > I want to configure Drools (CEP) to expire events when no longer needed. There are two scenarios: > ==SCENARIO A== > I configured Event with no explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is automatically calculated based on the constrains. If there is a rule with no temporal constraints, the expiration is INFINITE. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * If only ExampleRule1 loaded, expires INFINITE. Expected expires 0. ERROR? > * If ExampleRule1 loaded and ExampleRule2 loaded, expires 15s. Expected expires 15. OK! > To solve this situation a tried the following scenario: > == SCENARIO B== > I configured Event with explicit expires. In this scenario, if there is a rule with temporal constraints, the expiration is not taken into account because it is overriden by the explicit expires. The following example shows the scenario: > dialect "mvel" > declare Event > @role(event) > @expires(0s) > end > rule "ExampleRule1" > when > ( $a : Event(name == "event a") > then > System.out.println("ExampleRule1Triggered"); > end > rule "ExampleRule2" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("ExampleRule2Triggered"); > end > With the previous Event definition: > * ExampleRule1 is triggered and event removed. OK! > * ExampleRule2 is not triggered inserting two events because the first one expires. ERROR? > I suppose that SCENARIO B is not factible because explicit expires overrides implicit expires (according to issue DROOLS-586). > Could you please help me to solve this situation? Should Drools set inferred expiration time to 1ms when there are rules with no temporal constraints? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 10:42:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 7 Mar 2017 10:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar resolved WFLY-6863. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done > Excluded contexts which are not specific to a host should be excluded on all hosts > ---------------------------------------------------------------------------------- > > Key: WFLY-6863 > URL: https://issues.jboss.org/browse/WFLY-6863 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > With the following configuration: > {code} > loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" > loadMetricCapacity="1" > loadHistory="9" > loadDecayFactor="2" > stickySession="true" > stickySessionForce="false" > stickySessionRemove="true" > advertise="true" > advertiseGroupAddress="224.0.1.105" > advertisePort="23364" > advertiseInterface="10.40.4.50" > excludedContexts="ROOT,docs,manager,host-manager,examples" > /> > {code} > And these contexts in webapps: > {code} > clusterbench docs examples host-manager manager ROOT > {code} > One expects this output on Mod_cluster manger console: > {code} > Virtual Host 1: > Contexts: > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > {code} > It works, unless you configure additional VirtualHosts: > {code} > > LOCALHOST > prefix="localhost_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > > > KARM.BRQ.REDHAT.COM > prefix="localhost_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > > {code} > result: > {code} > Node worker1 (ajp://10.40.4.50:8009): > Enable Contexts Disable Contexts Stop Contexts > Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100 > Virtual Host 2: > Contexts: > /docs, Status: ENABLED Request: 0 Disable Stop > /manager, Status: ENABLED Request: 0 Disable Stop > /host-manager, Status: ENABLED Request: 0 Disable Stop > /examples, Status: ENABLED Request: 0 Disable Stop > /, Status: ENABLED Request: 0 Disable Stop > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > karm.brq.redhat.com > Virtual Host 1: > Contexts: > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > {code} > I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't. > WDYT? Is it possible to tweak with the Listener's configuration somehow? > THX. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 11:00:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 7 Mar 2017 11:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-977) PLAIN mechanism does not work with WildFlyElytronProvider for AuthenticationConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reassigned ELY-977: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > PLAIN mechanism does not work with WildFlyElytronProvider for AuthenticationConfiguration > ----------------------------------------------------------------------------------------- > > Key: ELY-977 > URL: https://issues.jboss.org/browse/ELY-977 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta25 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when WildFlyElytronProvider is set as provider for AuthenticationConfiguration then SASL PLAIN mechanism is stopped to work (see exception below). In case when WildFlyElytronProvider is removed then PLAIN mechanism works. It seems that Elytron does not implement SASL PLAIN mechanism correctly. > Thrown Exception: > {code} > java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.wildfly.security.elytron.SimpleClient$1.run(SimpleClient.java:67) > at org.wildfly.common.context.Contextual.run(Contextual.java:71) > at org.wildfly.security.elytron.SimpleClient.main(SimpleClient.java:48) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > ... 10 more > Caused by: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 6900a112 to /127.0.0.1:9990 of endpoint "management-client" <7c9695fa> > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:578) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:546) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:464) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:426) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:414) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:164) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:111) > ... 20 more > {code} > We request blocker flag because this issue blocks RFE EAP7-530. PLAIN is widely used SASL mechanism. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 11:00:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 7 Mar 2017 11:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8194) JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reassigned WFLY-8194: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-8194 > URL: https://issues.jboss.org/browse/WFLY-8194 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when PLAIN mechanism is used for Elytron SASL factories used by any of management-interfaces then JBoss CLI is not able to connect to the server. This issue happens with http-interface as well as native-interface. See Steps to Reproduce for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 11:01:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 7 Mar 2017 11:01:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-977) PLAIN mechanism does not work with WildFlyElytronProvider for AuthenticationConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina closed ELY-977. -------------------------- Resolution: Duplicate Issue > PLAIN mechanism does not work with WildFlyElytronProvider for AuthenticationConfiguration > ----------------------------------------------------------------------------------------- > > Key: ELY-977 > URL: https://issues.jboss.org/browse/ELY-977 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta25 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when WildFlyElytronProvider is set as provider for AuthenticationConfiguration then SASL PLAIN mechanism is stopped to work (see exception below). In case when WildFlyElytronProvider is removed then PLAIN mechanism works. It seems that Elytron does not implement SASL PLAIN mechanism correctly. > Thrown Exception: > {code} > java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.wildfly.security.elytron.SimpleClient$1.run(SimpleClient.java:67) > at org.wildfly.common.context.Contextual.run(Contextual.java:71) > at org.wildfly.security.elytron.SimpleClient.main(SimpleClient.java:48) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > ... 10 more > Caused by: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 6900a112 to /127.0.0.1:9990 of endpoint "management-client" <7c9695fa> > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:578) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:546) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:464) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:426) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:414) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:164) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:111) > ... 20 more > {code} > We request blocker flag because this issue blocks RFE EAP7-530. PLAIN is widely used SASL mechanism. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 11:21:00 2017 From: issues at jboss.org (Ron Sigal (JIRA)) Date: Tue, 7 Mar 2017 11:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7371) JAXRS endpoint - CDI injection to constructor doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374213#comment-13374213 ] Ron Sigal commented on WFLY-7371: --------------------------------- RESTEASY-1538 is closed. > JAXRS endpoint - CDI injection to constructor doesn't work > ---------------------------------------------------------- > > Key: WFLY-7371 > URL: https://issues.jboss.org/browse/WFLY-7371 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, REST > Affects Versions: 10.1.0.Final > Reporter: Tomas Remes > Assignee: Ron Sigal > > Deploying app with following JAXRS endpoint > {code} > @Path("/test") > public class MyTimeResource { > private final LocalDateTime dateTime; > @Inject > public MyTimeResource(LocalDateTime dateTime){ > this.dateTime = dateTime; > }; > } > {code} > is failing with following stack trace: > {noformat} > Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.example.microprofile.MyTimeResource > at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692) > at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:157) > at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:76) > at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:409) > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:250) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250) > at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133) > at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546) > at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > Note that app contains beans.xml so the JAXRS resource should be really managed by CDI. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 11:36:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 7 Mar 2017 11:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2363) Improve capability registration API In-Reply-To: References: Message-ID: Tomaz Cerar created WFCORE-2363: ----------------------------------- Summary: Improve capability registration API Key: WFCORE-2363 URL: https://issues.jboss.org/browse/WFCORE-2363 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar we should be able to do things like {code:java} context.getServiceTarget().addCapability(IO_WORKER_RUNTIME_CAPABILITY, workerService) .setInitialMode(ServiceController.Mode.ON_DEMAND) .install(); {code} instead of longer version with figuring out service name etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 11:38:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 7 Mar 2017 11:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9 modular params propagation to forked processes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFCORE-1859. --------------------------------- Assignee: Tomaz Cerar (was: Richard Opalka) Resolution: Done solved by using diffrent style parameters without spaces. for example {noformat} --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED {noformat} becomes: {noformat} --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED {noformat} JDK supports both. > Investigate and fix JDK9 modular params propagation to forked processes > ----------------------------------------------------------------------- > > Key: WFCORE-1859 > URL: https://issues.jboss.org/browse/WFCORE-1859 > Project: WildFly Core > Issue Type: Sub-task > Components: Server, Test Suite > Reporter: Richard Opalka > Assignee: Tomaz Cerar > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 12:07:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 7 Mar 2017 12:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) EAP 7.1.0.DR13 starts with errors and missing services in standalone-xts profile In-Reply-To: References: Message-ID: Ondra Chaloupka created WFLY-8314: ------------------------------------- Summary: EAP 7.1.0.DR13 starts with errors and missing services in standalone-xts profile Key: WFLY-8314 URL: https://issues.jboss.org/browse/WFLY-8314 Project: WildFly Issue Type: Bug Components: XTS Reporter: Ondra Chaloupka Assignee: Gytis Trikleris Priority: Critical When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "undertow"), ("server" => "default-server"), ("host" => "default-host"), ("setting" => "http-invoker") ]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] } 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0184: New missing/unsatisfied dependencies: service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) {code} This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 12:07:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 7 Mar 2017 12:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services in standalone-xts and standalone-rts profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated WFLY-8314: ---------------------------------- Summary: WFLY starts with errors and missing services in standalone-xts and standalone-rts profile (was: EAP 7.1.0.DR13 starts with errors and missing services in standalone-xts profile) > WFLY starts with errors and missing services in standalone-xts and standalone-rts profile > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Gytis Trikleris > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 12:07:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 7 Mar 2017 12:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services in standalone-xts and standalone-rts profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned WFLY-8314: ------------------------------------- Assignee: Ondra Chaloupka (was: Gytis Trikleris) > WFLY starts with errors and missing services in standalone-xts and standalone-rts profile > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 12:08:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 12:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-994) Add option to SSLContextBuilder to control if resulting SSLEngine is protected. In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-994: ------------------------------------ Summary: Add option to SSLContextBuilder to control if resulting SSLEngine is protected. Key: ELY-994 URL: https://issues.jboss.org/browse/ELY-994 Project: WildFly Elytron Issue Type: Enhancement Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta29 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:14:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:14:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7081) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned WFLY-7081: -------------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFLY-7081 > URL: https://issues.jboss.org/browse/WFLY-7081 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:16 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:16 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2365) Review custom-modifiable-realm resource in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7179 to WFCORE-2365: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2365 (was: WFLY-7179) Component/s: Security (was: Security) > Review custom-modifiable-realm resource in Elytron subsystem > ------------------------------------------------------------ > > Key: WFCORE-2365 > URL: https://issues.jboss.org/browse/WFCORE-2365 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:16 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:16 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2366) Complex type jdbc-realm in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7174 to WFCORE-2366: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2366 (was: WFLY-7174) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type jdbc-realm in Elytron subsystem > -------------------------------------------- > > Key: WFCORE-2366 > URL: https://issues.jboss.org/browse/WFCORE-2366 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in jdbc-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:16 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:16 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2367) Misleading description of identity-realm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7669 to WFCORE-2367: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2367 (was: WFLY-7669) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Misleading description of identity-realm > ---------------------------------------- > > Key: WFCORE-2367 > URL: https://issues.jboss.org/browse/WFCORE-2367 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > There is a misleading description of {{identity-realm}} in DMR [1]. It says _"A security realm definition where identities are represented in the management model."_ whereas an XSD documentation says _"Realm definition for a realm which contains a single pre-defined identity."_. > In general, the XSD description looks clearer to me. Moreover, the {{identities}} word may be misleading since {{identity-realm}}'s purpose is to _"to store one identity, with one attribute and no credential"_ [3]. Thus I would suggest to also change the description of {{attribute-values}} from > _"The values associated with the identities attribute."_ to something like _"The values associated with the identity attributes."_ > Suggestions for improvement: > * Change description {{identity-realm}} according to XSD > * Change description of {{attribute-values}} attr (in both DMR and XSD) > * to consider: unify descriptions in XSD and DMR > [1] /subsystem=elytron/identity-realm=somerealm:read-resource-description > [2] https://github.com/wildfly-security/elytron-subsystem/blob/master/src/main/resources/schema/wildfly-elytron_1_0.xsd#L412 > [3] HipChats's WildFly Elytron chat room on Nov 21 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:16 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:16 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2368) Missing default value of filter-name in Elytron ldap-realm in management model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7610 to WFCORE-2368: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2368 (was: WFLY-7610) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Missing default value of filter-name in Elytron ldap-realm in management model > ------------------------------------------------------------------------------ > > Key: WFCORE-2368 > URL: https://issues.jboss.org/browse/WFCORE-2368 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Elytron {{ldap-realm.identity-mapping.filter-name}} attribute has not assigned default value in CLI. However according to XSD it has default value (rdn-identifier={0}). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:17 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:17 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2369) Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8265 to WFCORE-2369: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2369 (was: WFLY-8265) Component/s: Security (was: Security) > Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2369 > URL: https://issues.jboss.org/browse/WFCORE-2369 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Bartosz Baranowski > Priority: Critical > > Quoting from [1]: > {quote} > DEBUG [org.wildfly.security] (default task-1) Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory "com.sun.jndi.ldap.LdapCtxFactory" from classloader ModuleClassLoader for Module "deployment.print-roles.war" from Service Module Loader [Root exception is java.lang.ClassNotFoundException: "com.sun.jndi.ldap.LdapCtxFactory" from [Module "deployment.print-roles.war" from Service Module Loader]] > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) > We can see from the stack trace the deployments class loader is being used. > I think by default the ClassLoader of the subsystem should be used i.e. that will have the common dependencies. However we may want to also add a module attribute so an alternative module can be specified for when creating the InitialDirContext. > {quote} > [1] https://issues.jboss.org/browse/JBEAP-8025?focusedCommentId=13370291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13370291 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:17 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:17 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2371) Unable to create custom credentail security factory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8151 to WFCORE-2371: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2371 (was: WFLY-8151) Component/s: Security (was: Security) > Unable to create custom credentail security factory > --------------------------------------------------- > > Key: WFCORE-2371 > URL: https://issues.jboss.org/browse/WFCORE-2371 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Dmitrii Tikhomirov > Priority: Blocker > > When I try to register custom credential security factory I get {{NoClassDefFoundError}} > {code} > 06:54:49,166 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.credfactory.AddCustomCredentialSecurityFactoryImpl in Module "org.jboss.customcredsecfacimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/credfactory/AddCustomCredentialSecurityFactoryImpl (Module "org.jboss.customcredsecfacimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/CredentialSecurityFactory > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 06:54:49,167 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory: org.jboss.msc.service.StartException in service org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/credfactory/AddCustomCredentialSecurityFactoryImpl (Module "org.jboss.customcredsecfacimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/CredentialSecurityFactory > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 06:54:49,168 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-credential-security-factory" => "CreaperTestAddCustomCredentialSecurityFactory") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/credfactory/AddCustomCredentialSecurityFactoryImpl (Module \"org.jboss.customcredsecfacimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/CredentialSecurityFactory"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory"] > } > {code} > That works in DR11 without issue > Here is implementation of custom credential security factory > {code:java|title=AddCustomCredentialSecurityFactoryImpl.java} > package org.wildfly.extras.creaper.commands.elytron.credfactory; > import java.security.GeneralSecurityException; > import java.util.Map; > import org.wildfly.extension.elytron.Configurable; > import org.wildfly.extension.elytron.capabilities.CredentialSecurityFactory; > import org.wildfly.security.credential.Credential; > public class AddCustomCredentialSecurityFactoryImpl implements CredentialSecurityFactory, Configurable { > @Override > public Credential create() throws GeneralSecurityException { > return null; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:17 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:17 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2373) Elytron DIGEST misconfiguration not handled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7700 to WFCORE-2373: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2373 (was: WFLY-7700) Component/s: Security (was: Security) > Elytron DIGEST misconfiguration not handled > ------------------------------------------- > > Key: WFCORE-2373 > URL: https://issues.jboss.org/browse/WFCORE-2373 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Priority: Critical > Labels: user_experience > > When realm name from web.xml and server configuration differs, user is not informed about that fact. > Could misconfiguration be handled by failing during application deployment as application requirement could not be satisfied? > {code:title=web.xml} > > DIGEST > Secured kingdom > > {code} > {code:title=standalone-elytron.xml} > > > > > > > > {code} > {code:title=server.log} > 17:06:18,278 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback > 17:06:18,282 TRACE [org.wildfly.security] (default task-1) New nonce generated AAAAAQAAGoxim7G7FMLLnVddA7s69JDh5sRsiZ5aEDhg7qf+dB2Rjs7xwrg=, using seed Secured kingdom > 17:06:22,308 TRACE [org.wildfly.security] (default task-2) Handling MechanismInformationCallback > 17:06:22,311 TRACE [org.wildfly.security] (default task-2) Handling AvailableRealmsCallback: realms = [Application Realm] > 17:06:22,312 TRACE [org.wildfly.security] (default task-2) Handling AvailableRealmsCallback: realms = [Application Realm] > 17:06:22,312 TRACE [org.wildfly.security] (default task-2) Handling RealmCallback: selected = [Secured kingdom] > 17:06:22,314 TRACE [org.wildfly.security] (default task-2) New nonce generated AAAAAgAAGo1TCzTJDpmA8HsI2fS4ZfJ60KbECZU6edCP9UepmGnyV93iP6c=, using seed Secured kingdom > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:18 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:18 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2375) Definition Credential Store with existing storage file but with wrong store password causes ugly failure-description. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7481 to WFCORE-2375: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2375 (was: WFLY-7481) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Definition Credential Store with existing storage file but with wrong store password causes ugly failure-description. > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2375 > URL: https://issues.jboss.org/browse/WFCORE-2375 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Definition Credential Store with existing storage file but with wrong store password causes ugly failure-description. > *How to reproduce* > Prepare credential store file (the easiest way is create credential store from scratch) > /subsystem=elytron/credential-store=cs_pass123:add(uri="cr-store://test/cs/ks-pass123.jceks?store.password=pass123;create.storage=true") > /subsystem=elytron/credential-store=cs_pass123/alias=dbPass:add(secret-value=passwordToDB) > Then I try to create Credential store with wrong store password to existing store file. > /subsystem=elytron/credential-store=cs_wrong_store_pass:add(uri="cr-store://test/cs/ks-pass123.jceks?store.password=pass123wrong;key.password=pass123=true") > *I can see this result:* > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store-client.cs_wrong_key_pass" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store-client.cs_wrong_key_pass: WFLYELY00004: Unable to start the service. > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09506: Cannot read credential storage file '/home/hsvabek/securityworkspace/VERIFICATION/2016_11_02_UX_testing/jboss-eap-7.1.0.DR7/standalone/data/cs/ks-pass123.jceks' for the store named 'cs_wrong_key_pass' > Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.cs_wrong_key_pass"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > *Suggestion for solution* > failure-description must not contain Exception or snippet stacktrace. > Description like that "Password to access credential store is incorrect." -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:17 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:17 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2372) filesystem-realm/identity fail-description message should contain new name of resource when name-rewriter is used and exception is related with it. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7535 to WFCORE-2372: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2372 (was: WFLY-7535) Component/s: Security (was: Security) > filesystem-realm/identity fail-description message should contain new name of resource when name-rewriter is used and exception is related with it. > --------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2372 > URL: https://issues.jboss.org/browse/WFCORE-2372 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Fail-description message should contain new name of resource when name-rewriter is used and exception is related with it. > *Scenario* > I want to create "identity" for Elytron filesystem-realm with constant-name-rewriter (or others *-name-rewriter(s) with same behaviour). > I am not able create more then one identity (because name is rewriten to same name). > It is right behaviour but fail-description contains confusing message with OLD resource name. > *Steps to reproduce* > * /subsystem=elytron/constant-name-rewriter=constantNR001:add(constant=constantName) > * /subsystem=elytron/filesystem-realm=fsRealm123:add(path=fs123, relative-to=jboss.server.config.dir,levels=1, name-rewriter=constantNR001) > * /subsystem=elytron/filesystem-realm=fsRealm123/identity=identity001:add() > I want add second identity with name "identity002" which is rewriten to *constantName*. I expect fail because the identity with *constantName* exists. > /subsystem=elytron/filesystem-realm=fsRealm123/identity=identity002:add() > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [identity002] already exists.", > "rolled-back" => true > } > {code} > *Suggestion for solution* > Message should contain some information about *constantName* at least. Information about nameRewriter will be also fine. > e.g. "WFLYELY01000: Identity with name [identity002] which was rewritten to [constantName] already exists. Name-rewriter was used." -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:18 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:18 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2376) There isn't possibility disable create CS file from scratch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7920 to WFCORE-2376: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2376 (was: WFLY-7920) Component/s: Security (was: Security) > There isn't possibility disable create CS file from scratch > ----------------------------------------------------------- > > Key: WFCORE-2376 > URL: https://issues.jboss.org/browse/WFCORE-2376 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Priority: Blocker > > There isn't possibility to disable create CS file from scratch. > Earlier we were able to set create.storage to true/false. > I can see problem in this scenario: > * I want to create new CS with path to existing CS file > * I fill wrong path > * Everything pass > But I want to use my CS file, not to create new one. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:18 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:18 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2377) Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8295 to WFCORE-2377: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2377 (was: WFLY-8295) Component/s: Security (was: Security) > Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2377 > URL: https://issues.jboss.org/browse/WFCORE-2377 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: ibm-java, kerberos > > On IBM java when obtain-kerberos-ticket is set to true user always get > {code} > javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible > {code} > According to ibm documentation [1] credsType=initiator and useKeytab are really incompatible. > This constraint can't be avoided once obtain-kerberos-ticket = true, because keytab path is required in model. > {code} > "path" => { > "type" => STRING, > "description" => "The path of the KeyTab to load to obtain the credential.", > "attribute-group" => "file", > "expressions-allowed" => true, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > And keytab is always set into Kerberos login module options > {code:title=GSSCredentialSecurityFactory.java} > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", (isServer && !obtainKerberosTicket) ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > } > {code} > [1] https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jgssDocs/jaas_login_user.html > I am not setting to blocker just because I am not sure about importance of obtain-kerberos-ticket. See my question JBEAP-9292. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:18 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:18 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2374) Elytron deployment depends on org.jboss.security.negotiation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7348 to WFCORE-2374: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2374 (was: WFLY-7348) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron deployment depends on org.jboss.security.negotiation > ------------------------------------------------------------ > > Key: WFCORE-2374 > URL: https://issues.jboss.org/browse/WFCORE-2374 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > > Based on wildfly documentation deployment which is secured by SPNEGO have to depend on {{org.jboss.security.negotiation}} module > Such configuration leads to WARN message beeing logged into server log > {code} > 08:35:05,388 WARN [org.jboss.as.dependency.private] (MSC service thread 1-8) WFLYSRV0018: Deployment "deployment.secured-webapp.war" is using a private module ("org.jboss.security.negotiation:main") which may be changed or removed in future versions without notice. > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:19 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2378) Regression against 7.0.GA, Kerberos over CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8222 to WFCORE-2378: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2378 (was: WFLY-8222) Component/s: Security (was: Security) > Regression against 7.0.GA, Kerberos over CLI > -------------------------------------------- > > Key: WFCORE-2378 > URL: https://issues.jboss.org/browse/WFCORE-2378 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > > It is not possible to authenticate to CLI using kerberos. > Same configuration works well against 7.0.0.GA > {code:titl=server.log on TRACE level} > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) configuredMaxReceiveBuffer=16777215 > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) relaxComplianceChecks=false > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) QOP={AUTH} > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) Our name 'remote at localhost.localdomain' > 17:32:21,113 INFO [stdout] (management I/O-2) Java config name: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb5-945898887586223869.conf > 17:32:21,113 INFO [stdout] (management I/O-2) Loaded from Java config > 17:32:21,114 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Unable to create SaslServer: javax.security.sasl.SaslException: ELY05029: [GSSAPI] Unable to create GSSContext [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)] > at org.wildfly.security.sasl.gssapi.GssapiServer.(GssapiServer.java:77) > at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44) > at org.wildfly.security.sasl.util.SecurityProviderSaslServerFactory.createSaslServer(SecurityProviderSaslServerFactory.java:77) > at org.wildfly.security.sasl.util.FilterMechanismSaslServerFactory.createSaslServer(FilterMechanismSaslServerFactory.java:88) > at org.wildfly.security.sasl.util.PropertiesSaslServerFactory.createSaslServer(PropertiesSaslServerFactory.java:56) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:79) > at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51) > at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72) > at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48) > at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51) > at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:59) > at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:50) > at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:259) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:125) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails) > at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:87) > at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:127) > at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193) > at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427) > at sun.security.jgss.GSSCredentialImpl.(GSSCredentialImpl.java:62) > at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154) > at org.wildfly.security.sasl.gssapi.GssapiServer.(GssapiServer.java:72) > ... 24 more > 17:32:21,115 TRACE [org.jboss.remoting.remote] (management I/O-2) Rejected invalid SASL mechanism GSSAPI > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 5 bytes > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 59 bytes > 17:32:21,116 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192] > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192] > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1 > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.Beta17-redhat-1" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service > 17:32:21,116 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 77 bytes > 17:32:21,116 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel > 17:32:21,118 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:32:21,118 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:32:21,118 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF > 17:32:21,118 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream > 17:32:21,441 INFO [org.jboss.eapqe.krbldap.eap7.utils.CustomCLIExecutor] (main) CLI executor output: > 17:32:21,441 INFO [org.jboss.eapqe.krbldap.eap7.utils.CustomCLIExecutor] (main) Java config name: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb5-945898887586223869.conf > Loaded from Java config > >>>KinitOptions cache name is /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb5cc > >>>DEBUG client principal is hnelson7259cb36-69b2-4e28-afb5-f668120a8dea at JBOSS.ORG > >>>DEBUG server principal is krbtgt/JBOSS.ORG at JBOSS.ORG > >>>DEBUG key type: 17 > >>>DEBUG auth time: Thu Feb 23 17:32:11 CET 2017 > >>>DEBUG start time: Thu Feb 23 17:32:11 CET 2017 > >>>DEBUG end time: Fri Feb 24 01:32:11 CET 2017 > >>>DEBUG renew_till time: null > >>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; > Found ticket for hnelson7259cb36-69b2-4e28-afb5-f668120a8dea at JBOSS.ORG to go to krbtgt/JBOSS.ORG at JBOSS.ORG expiring on Fri Feb 24 01:32:11 CET 2017 > Entered Krb5Context.initSecContext with state=STATE_NEW > Service ticket not found in the subject > >>> Credentials acquireServiceCreds: same realm > default etypes for default_tgs_enctypes: 17. > >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KdcAccessibility: reset > >>> KrbKdcReq send: kdc=localhost.localdomain UDP:6088, timeout=5000, number of retries =3, #bytes=648 > >>> KDCCommunication: kdc=localhost.localdomain UDP:6088, timeout=5000,Attempt =1, #bytes=648 > >>> KrbKdcReq send: #bytes read=634 > >>> KdcAccessibility: remove localhost.localdomain:6088 > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000 > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > Krb5Context setting mySeqNumber to: 951540638 > Krb5Context setting peerSeqNumber to: 0 > Created InitSecContextToken: > 0000: 01 00 6E 82 02 2C 30 82 02 28 A0 03 02 01 05 A1 ..n..,0..(...... > 0010: 03 02 01 0E A2 07 03 05 00 00 00 00 00 A3 82 01 ................ > 0020: 2C 61 82 01 28 30 82 01 24 A0 03 02 01 05 A1 0B ,a..(0..$....... > 0030: 1B 09 4A 42 4F 53 53 2E 4F 52 47 A2 2A 30 28 A0 ..JBOSS.ORG.*0(. > 0040: 03 02 01 00 A1 21 30 1F 1B 06 72 65 6D 6F 74 65 .....!0...remote > 0050: 1B 15 6C 6F 63 61 6C 68 6F 73 74 2E 6C 6F 63 61 ..localhost.loca > 0060: 6C 64 6F 6D 61 69 6E A3 81 E3 30 81 E0 A0 03 02 ldomain...0..... > 0070: 01 11 A2 81 D8 04 81 D5 AF 46 53 89 B1 22 66 A6 .........FS.."f. > 0080: C7 3C 9B 50 EB 36 7C D7 95 45 C9 46 BE A7 17 43 .<.P.6...E.F...C > 0090: CD 9E DB B1 34 F7 1E 89 A4 D8 7B 2D 37 F9 4D DE ....4......-7.M. > 00A0: 8C B6 9D 07 83 2B 3E BF 80 34 34 CB 52 B9 01 95 .....+>..44.R... > 00B0: AF 07 D1 8A 15 F8 7D 29 56 03 63 36 13 44 17 0B .......)V.c6.D.. > 00C0: C9 31 CD 6F 41 35 5D B2 5A 5F 25 27 20 8D DE 9A .1.oA5].Z_%' ... > 00D0: 1B A9 26 A9 22 E2 81 4C 18 BB F9 15 27 A4 75 68 ..&."..L....'.uh > 00E0: AF FE F4 2D 84 6D 44 24 73 C8 18 C0 3E 85 3E 0C ...-.mD$s...>.>. > 00F0: 6E 2C 89 FA 54 0B F6 E4 D3 C9 DA A3 61 14 5F 97 n,..T.......a._. > 0100: 1D FE 6A 70 D7 C7 9C D2 91 D7 D0 B0 88 20 A1 C8 ..jp......... .. > 0110: 53 42 DD 6B DB 3C 39 DC 2C DF 8A 52 C9 8B E4 0B SB.k.<9.,..R.... > 0120: AD 05 B8 81 08 0E D2 4E 83 F9 23 C8 DC F1 9A 42 .......N..#....B > 0130: BD 44 A4 DB CB E6 64 9B 9D 53 FA F3 4E 77 99 5F .D....d..S..Nw._ > 0140: AE 0C B3 52 11 B5 6E 65 FB 2C 6E D9 49 A4 81 E2 ...R..ne.,n.I... > 0150: 30 81 DF A0 03 02 01 11 A2 81 D7 04 81 D4 13 3B 0..............; > 0160: BB 37 F0 B9 F9 C3 60 E0 80 DA A2 8D 0C E9 8A 34 .7....`........4 > 0170: DA E1 55 CB 4F 09 EB 36 3A F4 68 D3 90 D9 0F CD ..U.O..6:.h..... > 0180: 0F BA 50 1C A9 5C 70 84 1B CD 43 12 33 41 8A CA ..P..\p...C.3A.. > 0190: 46 B0 21 4B 10 D7 22 5C EC D0 79 C1 0D 5E 1C 58 F.!K.."\..y..^.X > 01A0: 64 7C 75 43 77 96 82 1F 3A AD A2 C1 C4 9B 96 5B d.uCw...:......[ > 01B0: 0D 1B DC 60 BD 76 91 69 53 DE 2F 34 CF 9E 0B EE ...`.v.iS./4.... > 01C0: 8D D9 98 E0 37 AB 8D 2F 0D 61 B5 8C 10 43 20 2B ....7../.a...C + > 01D0: 6D 36 E1 0F 5B 23 22 8A 76 1B 55 0C 2E A1 8C D7 m6..[#".v.U..... > 01E0: 8C 6F D2 07 2B 26 3B BF 54 74 9B 76 4A 78 2B E8 .o..+&;.Tt.vJx+. > 01F0: 70 E3 81 08 E9 8B A3 F1 69 A3 E2 BE 1D 5B 8F 3A p.......i....[.: > 0200: 0F 34 3D 2D 01 69 C4 FC 67 FB 13 4B F3 D9 BE 94 .4=-.i..g..K.... > 0210: 9D 24 75 92 32 13 4B 8B 18 D0 FF 3B F9 51 19 90 .$u.2.K....;.Q.. > 0220: 44 63 61 BF A0 91 9E 76 9D 42 AA 3D B3 46 64 0A Dca....v.B.=.Fd. > 0230: 0D 19 .. > Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9990: Authentication failed: all available authentication mechanisms failed: > GSSAPI: Server rejected authentication > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:19 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2380) JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8194 to WFCORE-2380: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2380 (was: WFLY-8194) Component/s: Security (was: Security) > JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-2380 > URL: https://issues.jboss.org/browse/WFCORE-2380 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when PLAIN mechanism is used for Elytron SASL factories used by any of management-interfaces then JBoss CLI is not able to connect to the server. This issue happens with http-interface as well as native-interface. See Steps to Reproduce for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:19 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2381) CS tool, review usage documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8191 to WFCORE-2381: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2381 (was: WFLY-8191) Component/s: Security (was: Security) > CS tool, review usage documentation > ----------------------------------- > > Key: WFCORE-2381 > URL: https://issues.jboss.org/browse/WFCORE-2381 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store > > Current usage output > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store > -a | -e | -h | -r | -v [-c] [-f] [-i > ] [-l ] [-p ] [-s ] [-t ] [-u ] [-x > ] > -a,--add Add new alias to the credential store > -c,--create Create credential store [true/false] > -e,--exists Check if alias exists within the credential store > -f,--summary Print summary, especially command how to create > this credential store > -h,--help Get help with usage of this command > -i,--iteration Iteration count for for final masked password of > the credential store > -l,--location Location of credential store storage file > -p,--password Password for credential store > -r,--remove Remove alias from the credential store > -s,--salt Salt to apply for final masked password of the > credential store > -t,--type Credential store type > -u,--uri Configuration URI for credential store > -v,--aliases Display all aliases > -x,--secret Password credential value > {code} > IMO suffers with these issues: > - it introduce misleading placeholder. It is not used now. It is prepared for future needs. Remove it please. > - it is not obvious which options are required in conjuction with e.g. --add option > - use GNU usage syntax. e.g. [] instead of <> > - sometimes it will be more useful to replace with some meaningful name, e.g. --add alias > I suggest something like > {code} > java -jar wildfly-elytron-tool.jar credential-store required_option [options] > java -jar wildfly-elytron-tool.jar credential-store --add alias -u arg ... [-c] ... > java -jar wildfly-elytron-tool.jar credential-store --remove alias -u arg [-c] ... > ... > One of these is required > -a,--add alias Add new alias to the credential store > -e,--exists alias Check if alias exists within the credential store > -h,--help Get help with usage of this command > -r,--remove alias Remove alias from the credential store > -v,--aliases Display all aliases > Options > -c,--create Create credential store [true/false] > -f,--summary Print summary, especially command how to create this credential store > -i,--iteration count Iteration count for for final masked password of the credential store > -l,--location file Location of credential store storage file > -p,--password store_password Password for credential store > -s,--salt arg Salt to apply for final masked password of the credential store > -t,--type arg Credential store type > -u,--uri arg Configuration URI for credential store > -x,--secret value Password credential value > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:19 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2379) Synchronize XSD and DMR description of credential-store attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8157 to WFCORE-2379: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2379 (was: WFLY-8157) Component/s: Security (was: Security) > Synchronize XSD and DMR description of credential-store attributes > ------------------------------------------------------------------ > > Key: WFCORE-2379 > URL: https://issues.jboss.org/browse/WFCORE-2379 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store > > Use XSD description in DMR description, because description in XSD is better for attributes > * provider-name > * providers > * other-providers > * relative-to > * uri (DMR description contains wrong vault://) > For {{type}} attribute use this description in both XSD and DMR: "The credential store type, e.g. KeyStoreCredentialStore" . Now there is mentioned wrongly KeyStorePasswordStore > {code:xml|title=XSD} > > > > The credential store type, e.g. KeyStorePasswordStore. > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:20 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:20 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2382) Doesn't work to define {EXT} command with parameters. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7876 to WFCORE-2382: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2382 (was: WFLY-7876) Component/s: Security (was: Security) > Doesn't work to define {EXT} command with parameters. > ----------------------------------------------------- > > Key: WFCORE-2382 > URL: https://issues.jboss.org/browse/WFCORE-2382 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > Doesn't work to define {EXT} command with parameters. > For {CMD} is everything OK. > *You can try it by this command (you must replace path to some real file).* > /subsystem=elytron/credential-store=CredStore011:add(uri="cr-store://test/cs999.jceks", credential-reference={type=COMMAND, clear-text="{EXT}/real/path/to/script/pass-ely.sh par011"}) > *Result is this error msg:* > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.CredStore011" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.CredStore011: WFLYELY00004: Unable to start the service. > Caused by: java.io.IOException: Cannot run program \"/real/path/to/script/pass-ely.sh par011\": error=2, No such file or directory > Caused by: java.io.IOException: error=2, No such file or directory"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store.CredStore011"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:20 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:20 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2383) Elytron subsystem is unable to configure SunPKCS11 provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8108 to WFCORE-2383: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2383 (was: WFLY-8108) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Elytron subsystem is unable to configure SunPKCS11 provider > ----------------------------------------------------------- > > Key: WFCORE-2383 > URL: https://issues.jboss.org/browse/WFCORE-2383 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 4.0.0.Alpha1 > > > Trying to configure server to run in FIPS mode using subsystem capabilities. > I can't configure throught subsystem same as in java.security file: > {code:title=java.security} > security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/pkcs11.cfg > {code} > because if I try to pass configuration file or configuration > {code} > /subsystem=elytron/provider-loader=fips:add(class-names=[sun.security.pkcs11.SunPKCS11], path=/usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/pkcs11.cfg) > /subsystem=elytron/provider-loader=fips:add(class-names=[sun.security.pkcs11.SunPKCS11], configuration={ \ > name=nssModule, value=fips \ > name=nssSecmodDirectory, value=/usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/fipsdb \ > name=nssLibraryDirectory, value=/usr/lib64 \ > name=name, value=testPkcs \ > name=nssDbMode, value=readOnly \ > } > {code} > I get exception > {code} > 10:46:28,630 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.providers.fips: org.jboss.msc.service.StartException in service org.wildfly.security.providers.fips: java.security.ProviderException: SunPKCS11 requires configuration file argument > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:185) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:143) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.ProviderException: SunPKCS11 requires configuration file argument > at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:98) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at java.lang.Class.newInstance(Class.java:442) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:156) > ... 7 more > 10:46:28,630 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("provider-loader" => "fips") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.fips" => "org.jboss.msc.service.StartException in service org.wildfly.security.providers.fips: java.security.ProviderException: SunPKCS11 requires configuration file argument > Caused by: java.security.ProviderException: SunPKCS11 requires configuration file argument"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.providers.fips"] > } > {code} > It occures because loading of providers is in subsystem implemented in 2 steps > * create provider instance (call noargs constructor) > * optionally load configuration > But {{sun.security.pkcs11.SunPKCS11}} can't be created without configuration [1] > [1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/security/pkcs11/SunPKCS11.java#98 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:20 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:20 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2384) Elytron subsystem is unable to configure com.sun.net.ssl.internal.ssl.Provider in FIPS mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8112 to WFCORE-2384: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2384 (was: WFLY-8112) Component/s: Security (was: Security) > Elytron subsystem is unable to configure com.sun.net.ssl.internal.ssl.Provider in FIPS mode > ------------------------------------------------------------------------------------------- > > Key: WFCORE-2384 > URL: https://issues.jboss.org/browse/WFCORE-2384 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > Trying to configure server to run in FIPS mode using subsystem capabilities. > I can't configure throught subsystem same as in java.security file: > {code:title=java.security} > security.provider.5=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-testPkcs > {code} > because there is no possibility in subsystem to call provider constructor with arguments (I don't mean providers configuration) > Subsystem implements provider loading in 2 steps > * create provider instance (call noargs constructor) > * optionally load configuration > But to create {{com.sun.net.ssl.internal.ssl.Provider}} in FIPS mode constructor with arguments must be called [1] > [1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/net/ssl/internal/ssl/Provider.java#49 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:20 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:20 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2385) There are two different error messages for adding duplicate record to CS by same command. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8005 to WFCORE-2385: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2385 (was: WFLY-8005) Component/s: Security (was: Security) > There are two different error messages for adding duplicate record to CS by same command. > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2385 > URL: https://issues.jboss.org/browse/WFCORE-2385 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > There are two different error messages for adding duplicate record to CS by same command. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/customcredCS007.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret) > {code} > And now we try add there same alias with exactly same name and with name in uppercase > {code} > /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"elytron\"), > (\"credential-store\" => \"cs007\"), > (\"alias\" => \"alias001\") > ]", > "rolled-back" => true > } > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=ALIAS001:add(secret-value=secret) > { > "outcome" => "failed", > "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store", > "rolled-back" => true > } > {code} > You can see different error message. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:21 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:21 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7993 to WFCORE-2386: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2386 (was: WFLY-7993) Component/s: Security (was: Security) > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > Error401 - Unauthorized > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > Error401 - Unauthorized > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:21 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:21 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2387) Elytron subsystem requires user to input OIDs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7355 to WFCORE-2387: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2387 (was: WFLY-7355) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron subsystem requires user to input OIDs > --------------------------------------------- > > Key: WFCORE-2387 > URL: https://issues.jboss.org/browse/WFCORE-2387 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Labels: user_experience > > On couple of places in elytron subsystem raw oids are expected from user input, e.g. {{2.5.4.4}} . Is there chance some aliasing could be introduced? So for example human readable {{surname}} can be used? > * kerberos-security-factory > ** mechanism-oids > * x500-principal-decoder > ** oid > ** required-oids -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:21 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:21 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2388) Elytron key-managers requires set credential-reference which is wrongly marked as optional. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7435 to WFCORE-2388: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2388 (was: WFLY-7435) Component/s: Security (was: Security) > Elytron key-managers requires set credential-reference which is wrongly marked as optional. > ------------------------------------------------------------------------------------------- > > Key: WFCORE-2388 > URL: https://issues.jboss.org/browse/WFCORE-2388 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > In EAP7.1.0.DR7 Elytron key-managers uses credential-reference with clear-text attribute for password instead of password attribute. > But there is problem with credential-reference element which is wrongly marked as optional. > Please set this element on mandatory with respect to this issue https://issues.jboss.org/browse/WFLY-7125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:21 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:21 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2389) Definition Credential Store with non-existent storage file causes ugly failure-description with Exception. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7478 to WFCORE-2389: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2389 (was: WFLY-7478) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Definition Credential Store with non-existent storage file causes ugly failure-description with Exception. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2389 > URL: https://issues.jboss.org/browse/WFCORE-2389 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Definition Credential Store with non-existent storage file causes ugly failure-description with Exception. > When I define Credential > Store for non-existent JCEKS file > {code} > /subsystem=elytron/credential-store=cs_not_found_exception:add(uri="cr-store://test/cs/keystore-non-existent.jceks?store.password=pass123") > {code} > then I got very ugly failure description > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store-client.cs_not_found_exception" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store-client.cs_not_found_exception: WFLYELY00004: Unable to start the service. > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09506: Cannot read credential storage file '/home/hsvabek/securityworkspace/VERIFICATION/2016_11_02_UX_testing/jboss-eap-7.1.0.DR7/standalone/data/cs/keystore-not_exists.jceks' for the store named 'cs_not_found_exception' > Caused by: java.io.FileNotFoundException: /home/hsvabek/securityworkspace/VERIFICATION/2016_11_02_UX_testing/jboss-eap-7.1.0.DR7/standalone/data/cs/keystore-not_exists.jceks (No such file or directory)"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.cs_not_found_exception"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > *Suggestion for solution* > failure-description must not contain Exception or snippet stacktrace. > Description like that "Credential store file XYZ doesn't exist. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:22 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:22 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2391) No log messages comming from Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7126 to WFCORE-2391: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2391 (was: WFLY-7126) Component/s: Security (was: Security) > No log messages comming from Elytron > ------------------------------------ > > Key: WFCORE-2391 > URL: https://issues.jboss.org/browse/WFCORE-2391 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:21 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:21 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2390) Review filesystem-realm resource in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7180 to WFCORE-2390: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2390 (was: WFLY-7180) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Review filesystem-realm resource in Elytron subsystem > ----------------------------------------------------- > > Key: WFCORE-2390 > URL: https://issues.jboss.org/browse/WFCORE-2390 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:22 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:22 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7778 to WFCORE-2392: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2392 (was: WFLY-7778) Component/s: Security (was: Security) > Remoting EJB identity propagation does not work with Elytron > ------------------------------------------------------------ > > Key: WFCORE-2392 > URL: https://issues.jboss.org/browse/WFCORE-2392 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron-legacy-test-fails > > Even througth succesful obtaining LoginContext, identity is not propagated in EJB call. > Identity is unauthorized on server side. > *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference. > Often error message: > {code:java} > SaslException: Authentication failed: all available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:22 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:22 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2393) Elytron expects certificate in PEM format as user input In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7572 to WFCORE-2393: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2393 (was: WFLY-7572) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron expects certificate in PEM format as user input > ------------------------------------------------------- > > Key: WFCORE-2393 > URL: https://issues.jboss.org/browse/WFCORE-2393 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Pedro Igor > Labels: user_experience > > In {{/token-realm/public-key}} attribute there is certificate in PEM format expected, which I consider to be user un-friendly. > I wonder couldn't that be accomplished by leveraging key-store/trust-manager capability? > {code} > "public-key" => { > "type" => STRING, > "description" => "A public key in PEM Format. During validation, if a public key is provided, signature will be verified based on the key you provided here.", > "expressions-allowed" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:23 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:23 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2395) There is NoSuchProviderException when we want to create our custom credential store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7881 to WFCORE-2395: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2395 (was: WFLY-7881) Component/s: Security (was: Security) > There is NoSuchProviderException when we want to create our custom credential store. > ------------------------------------------------------------------------------------ > > Key: WFCORE-2395 > URL: https://issues.jboss.org/browse/WFCORE-2395 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > There is NoSuchProviderException when we want to create our custom credential store. > *How to reproduce* > # Create module > Set your own path to customcredstoreprovider.jar downloaded from attachment > {code} > module add --name=org.jboss.customcredstore --resources=/tmp/customcredstoreprovider.jar --dependencies=org.wildfly.security.elytron,org.wildfly.extension.elytron --slot=main > {code} > # Create provider loader > {code} > /subsystem=elytron/provider-loader=cust001:add(providers=[{class-names=[org.jboss.as.test.integration.security.credential.store.CustomElytronProvider],module=org.jboss.customcredstore,load-services=true}],register=true) > {code} > # Create credential store > {code} > /subsystem=elytron/credential-store=cs0123456:add(uri="cr-store://test/customcredCS123.jceks?create.storage=true", provider=org.jboss.as.test.integration.security.credential.store.CustomElytronProvider, provider-loader=cust001, credential-reference={clear-text=pass123}) > {code} > *And the result is:* > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.cs0123456" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.cs0123456: WFLYELY00004: Unable to start the service. > Caused by: java.security.NoSuchProviderException: org.jboss.as.test.integration.security.credential.store.CustomElytronProvider"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store.cs0123456"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:23 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:23 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2394) Coverity static analysis, dereference after null check, KeyStoreCredentialStore (Elytron) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8093 to WFCORE-2394: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2394 (was: WFLY-8093) Component/s: Security (was: Security) > Coverity static analysis, dereference after null check, KeyStoreCredentialStore (Elytron) > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2394 > URL: https://issues.jboss.org/browse/WFCORE-2394 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > Coverity static-analysis scan found possible call on null object in KeyStoreCredentialStore class: > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564274&defectInstanceId=2359189&mergedDefectId=1402109 > In if branch where flow will get only if location is null, location is dereferenced: > {code:java|title=KeyStoreCredentialStore.java} > if (location != null && Files.exists(location)) > try (InputStream fileStream = Files.newInputStream(location)) { > keyStore.load(fileStream, getStorePassword(protectionParameter)); > enumeration = keyStore.aliases(); > } catch (GeneralSecurityException | IOException e) { > throw log.cannotInitializeCredentialStore(e); > } else if (create) { > try { > keyStore.load(null, null); > enumeration = Collections.emptyEnumeration(); > } catch (CertificateException | IOException | NoSuchAlgorithmException e) { > throw log.cannotInitializeCredentialStore(e); > } > } else { > throw log.automaticStorageCreationDisabled(location.toString()); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:23 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:23 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2397) Elytron simple-regex-realm-mapper "pattern" attribute has wrong description. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7551 to WFCORE-2397: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2397 (was: WFLY-7551) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Elytron simple-regex-realm-mapper "pattern" attribute has wrong description. > ---------------------------------------------------------------------------- > > Key: WFCORE-2397 > URL: https://issues.jboss.org/browse/WFCORE-2397 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Elytron simple-regex-realm-mapper "pattern" attribute has wrong description [1]. > *Actual description* > {code} > The regular expression to use for this NameRewriter. > {code} > *Expected description* > Some like that (from DMR): > {code} > The regular expression which must contain at least one capture group to extract the realm from the name. > {code} > [1] https://github.com/wildfly-security/elytron-subsystem/blob/580569d17cb6c3b1e823a2149b156c36d186f0dd/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1969 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:23 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:23 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2398) Legacy Kerberos in management, EAP search for HTTPS/localhost ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7994 to WFCORE-2398: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2398 (was: WFLY-7994) Component/s: Security (was: Security) > Legacy Kerberos in management, EAP search for HTTPS/localhost ticket > -------------------------------------------------------------------- > > Key: WFCORE-2398 > URL: https://issues.jboss.org/browse/WFCORE-2398 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > > Accessing management interface secured by Kerberos + TLS causes EAP requests from KDC ticket HTTPS/localhost. Which was not necessary in EAP 7.0 and it worked fine with HTTP/localhost service name > {code:title=server.log} > 14:20:19,321 TRACE [org.jboss.as.domain.management.security] (management task-7) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match. > 14:20:19,322 TRACE [org.jboss.as.domain.management.security] (management task-7) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 14:20:19,322 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,524 WARN [org.apache.directory.server.protocol.shared.kerberos.StoreUtils] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain at JBOSS.ORG > 14:20:19,524 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain at JBOSS.ORG > 14:20:19,524 WARN [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler] (NioDatagramAcceptor-3) Server not found in Kerberos database (7) > 14:20:19,525 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) Server not found in Kerberos database (7) > 14:20:19,528 WARN [org.apache.http.impl.auth.HttpAuthenticator] (main) NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - Server not found in Kerberos database)) > 14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match. > 14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > [Krb5LoginModule]: Entering logout > [Krb5LoginModule]: logged out Subject > {code} > Also see network dump krb_https_management.pcap in attachement, where TGS-REQ for HTTPS/localhost is captured. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:23 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:23 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2396) credential-store and authentication-context in Elytron dir-context should be mutually exclusive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8172 to WFCORE-2396: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2396 (was: WFLY-8172) Component/s: Security (was: Security) > credential-store and authentication-context in Elytron dir-context should be mutually exclusive > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2396 > URL: https://issues.jboss.org/browse/WFCORE-2396 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > To avoid possibility when two different credentials are configured in Elytron dir-context, its attributes credential-store and authentication-context should be mutually exclusive. > This jira is based on discussion in JBEAP-8026. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:24 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:24 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2401) Permission added using list-add should be validated before adding to Elytron constant-permission-mapper or simple-permission-mapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7678 to WFCORE-2401: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2401 (was: WFLY-7678) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Permission added using list-add should be validated before adding to Elytron constant-permission-mapper or simple-permission-mapper > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2401 > URL: https://issues.jboss.org/browse/WFCORE-2401 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > > Permission object added using {{list-add}} operation should be validated before being added to {{constant-permission-mapper}} or {{simple-permission-mapper}}. > The reproducer should behave like > {noformat} > [standalone at localhost:9990 /] /subsystem=elytron/constant-permission-mapper=cpm:add(permissions=[{class-name=java.io.FilePermission}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.cpm" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.cpm: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [java.io.FilePermission]. > Caused by: java.lang.IllegalArgumentException: invalid actions mask"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.cpm"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:24 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:24 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2400) Review provider-loader resource in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7177 to WFCORE-2400: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2400 (was: WFLY-7177) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Review provider-loader resource in Elytron subsystem > ---------------------------------------------------- > > Key: WFCORE-2400 > URL: https://issues.jboss.org/browse/WFCORE-2400 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 4.0.0.Alpha1 > > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:24 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:24 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2399) Removing and re-adding alias to credential store leads to Duplicate resource failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8144 to WFCORE-2399: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2399 (was: WFLY-8144) Component/s: Security (was: Security) > Removing and re-adding alias to credential store leads to Duplicate resource failure > ------------------------------------------------------------------------------------ > > Key: WFCORE-2399 > URL: https://issues.jboss.org/browse/WFCORE-2399 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store > > When an alias is removed from a credential store and added once more, the {{add}} operation fails with Duplicate resource message. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:24 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:24 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7125 to WFCORE-2402: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2402 (was: WFLY-7125) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Required attributes of elytron key-store creation add operation > --------------------------------------------------------------- > > Key: WFCORE-2402 > URL: https://issues.jboss.org/browse/WFCORE-2402 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Minimal CLI command to create key store is > {code} > /subsystem=elytron/key-store=server:add(type="JKS") > {code} > But it has these problems: > * Password attribute has to be required. I can't think of case when that could be ommited. > * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:25 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:25 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2403) CS tool, omitting required param leads to NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8187 to WFCORE-2403: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2403 (was: WFLY-8187) Component/s: Security (was: Security) > CS tool, omitting required param leads to NPE > --------------------------------------------- > > Key: WFCORE-2403 > URL: https://issues.jboss.org/browse/WFCORE-2403 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: credential-store > > Omitting required param leads to NPE, e.g. when adding alias without password (-p --password) > {code} > java -jar wildfly-elytron-tool.jar credential-store -a test_alis -x admin123 -c -u "cr-store://store-test-1?create=true" -salt 12345678 --iteration 230 > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} > Help does not document required options. If required option is ommited user is not informed about which parameter is missing. So effectivelly user have no way to find out required parameters. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:25 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:25 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2404) Elytron, unable to create custom principal transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8152 to WFCORE-2404: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2404 (was: WFLY-8152) Component/s: Security (was: Security) > Elytron, unable to create custom principal transformer > ------------------------------------------------------ > > Key: WFCORE-2404 > URL: https://issues.jboss.org/browse/WFCORE-2404 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > When I try to register custom principal transformer I get {{NoClassDefFoundError}} > {code} > 07:11:37,203 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.mapper.AddCustomPrincipalTransformerImpl in Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 07:11:37,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 07:11:37,207 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-principal-transformer" => "CreaperTestAddCustomPrincipalTransformer") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer" => "org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module \"org.jboss.customprincipaltransformerimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer"] > } > {code} > That works in DR11 without issue > Here is implementation of used custom prncipal transformer > {code:java|title=AddCustomPrincipalTransformerImpl.java} > package org.wildfly.extras.creaper.commands.elytron.mapper; > import org.wildfly.extension.elytron.Configurable; > import java.security.Principal; > import java.util.Map; > import org.wildfly.extension.elytron.capabilities.PrincipalTransformer; > public class AddCustomPrincipalTransformerImpl implements PrincipalTransformer, Configurable { > @Override > public Principal apply(Principal p) { > return p; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:25 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:25 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2405) Credential store file isn't created when we add there new entry in embed-server mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7983 to WFCORE-2405: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2405 (was: WFLY-7983) Component/s: Security (was: Security) > Credential store file isn't created when we add there new entry in embed-server mode. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2405 > URL: https://issues.jboss.org/browse/WFCORE-2405 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Credential store file isn't created when we add there new entry in embed-server mode. > * ./bin/jboss-cli.sh > * embed-server > * /subsystem=elytron/credential-store=store001:add(uri="cr-store://test/store001.jceks?create=true", credential-reference={clear-text=pass123}) > * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) > store001.jceks file should be created in JBOSS_HOME directory, but it doesn't. > When I stop embedded server and start standalone server everything work fine. > * stop-embedded-server > * ./bin/standalone.sh > * connect > * /subsystem=elytron/credential-store=store001/alias=alias001:add(secret-value=secretValue) > store001.jceks file is correctly created in JBOSS_HOME directory. > *NOTE:* > When I copy there store001.jceks file to JBOSS_HOME directory with same password to access as expected then entry is added correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:25 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:25 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2406) Credential store alias with upper-case letters can't be added when Java assertions are enabled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8137 to WFCORE-2406: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2406 (was: WFLY-8137) Component/s: Security (was: Security) > Credential store alias with upper-case letters can't be added when Java assertions are enabled > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-2406 > URL: https://issues.jboss.org/browse/WFCORE-2406 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Brian Stansberry > Priority: Critical > > When Java assertions are enable then adding credential store entry (alias) with upper case letters fails with assertion error. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:26 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2407) ReAuth does not work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7779 to WFCORE-2407: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2407 (was: WFLY-7779) Component/s: Security (was: Security) > ReAuth does not work with Elytron > --------------------------------- > > Key: WFCORE-2407 > URL: https://issues.jboss.org/browse/WFCORE-2407 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Darran Lofthouse > Labels: elytron-legacy-test-fails > > Following way of change identity from servlet does not work: > {code:java} > LoginContext lc = getCLMLoginContext(username, password); > lc.login(); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:26 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2408) Description of Elytron oauth2-introspection resource is copy/pasted from jwt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7676 to WFCORE-2408: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2408 (was: WFLY-7676) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Description of Elytron oauth2-introspection resource is copy/pasted from jwt > ---------------------------------------------------------------------------- > > Key: WFCORE-2408 > URL: https://issues.jboss.org/browse/WFCORE-2408 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Description of {{oauth2-introspection}} resource from Elytron {{token-realm}} is copy/pasted from description of {{jwt}}. > It is similar as WFLY-7573, but its description (and also its linked fix) talks only about description of attributes. This Jira is related to description of whole resource which currently says: > "A token validator to be used in conjunction with a token-based realm that handles security tokens based on the JWT/JWS standard." -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:26 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2409) Review elytron kerberos-security-factory resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7259 to WFCORE-2409: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2409 (was: WFLY-7259) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Review elytron kerberos-security-factory resource > ------------------------------------------------- > > Key: WFCORE-2409 > URL: https://issues.jboss.org/browse/WFCORE-2409 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > * {{mechanism-oids}} > ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} > ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. > * {{minimum-remaining-lifetime}} > ** please, specify units in documentation, e.g. seconds/minutes > * {{relative-to}} > ** as just path reference can be used here, probably should be just "expressions-allowed" => false > ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute." > * {{server}} > ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation. > * {{for-hosts}} > ** comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:26 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2410) Wrong resource and operation descriptions for Elytron filesystem-realm in management model and XSD In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7582 to WFCORE-2410: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2410 (was: WFLY-7582) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Wrong resource and operation descriptions for Elytron filesystem-realm in management model and XSD > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-2410 > URL: https://issues.jboss.org/browse/WFCORE-2410 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > There are some wrong or insufficient resource and operation description for Elytron filesystem-realm in CLI: > * attribute {{levels}} for filesystem-realm - description says "The number of levels of directory hashing to apply.", but created directory structure does not use any hashing. Example how it works: when levels is set to 3 then for user admin following directory structure and file a/d/m/admin.xml is used. Description of levels should be fixed. This should be also fixed in XSD. > * description of {{digest}} password encryption/hash mechanisms in {{set-password}} operation for identity of filesystem-realm says "A password using a salted digest." which is wrong. It seems it is copy-pasted from {{salted-simple-digest}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:27 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:27 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2411) CS with {CMD} or {EXT} pass doesn't persist type=COMMAND to configuration -> after reload it doesn't work. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7869 to WFCORE-2411: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2411 (was: WFLY-7869) Component/s: Security (was: Security) > CS with {CMD} or {EXT} pass doesn't persist type=COMMAND to configuration -> after reload it doesn't work. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2411 > URL: https://issues.jboss.org/browse/WFCORE-2411 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Priority: Blocker > > This issue blocks verification of this RFE https://issues.jboss.org/browse/EAP7-533. > CS with {CMD} or {EXT} pass doesn't persist type=COMMAND to configuration -> after reload it doesn't work. > You can try it by this command (you must replace path to some real file. > /subsystem=elytron/credential-store=CredStoreCMD:add(uri="cr-store://test/cs444.jceks", credential-reference={type=COMMAND, clear-text="{CMD}/real/path/to/pass-ely.sh"}) > Once the command is successful executed: > # stop the server (not necessary) > # check standalone.xml > Given CredentialStore is persisted without attribute *type="COMMAND"* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:27 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:27 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2412) Complex type key-store in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7166 to WFCORE-2412: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2412 (was: WFLY-7166) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type key-store in Elytron subsystem > ------------------------------------------- > > Key: WFCORE-2412 > URL: https://issues.jboss.org/browse/WFCORE-2412 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in key-store resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:28 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2414) Coverity static analysis: Non-Serializable SecurityIdentity is contained in Serializable ElytronAccount In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7950 to WFCORE-2414: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2414 (was: WFLY-7950) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Coverity static analysis: Non-Serializable SecurityIdentity is contained in Serializable ElytronAccount > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2414 > URL: https://issues.jboss.org/browse/WFCORE-2414 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > Coverity static analysis found Serializable ElytronAccount contains non-Serializable SecurityIdentity. > https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=8622358&defectInstanceId=2151938&mergedDefectId=1389592 > Please resolve this inconsistent situation. > By dev feedback SecurityIdentity can't be made Serializable. Rework to remove SecurityIdentity from ElytronAccount was suggested. > {code:title=hipchat.log} > [3:23 PM] Martin Choma: Shouldn't be SecurityIdentity Serializable? - because of HttpSession replication? > [3:23 PM] Darran Lofthouse: No it can't be > [3:24 PM] Darran Lofthouse: it is backed by implementation as well as state > [3:25 PM] David M. Lloyd: right it would essentially be a security hole to be able to deserialize an identity > [3:26 PM] David M. Lloyd: among other problems > [3:26 PM] Darran Lofthouse: on the far side we restore the identity instead of deserializing it > [3:31 PM] Martin Choma: I got it. Thing is static analyzer is complaining elytron-web ElytronAccount (Serializable class) is referencing SecurityIdentity, but probably problem is ElytronAccount does not have to be mark as Serializable, right? > [3:34 PM] Darran Lofthouse: @MartinChoma we may be able to re-work that and remove the reference to SI > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:28 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2415) credential-reference must have defined combinations of constraints In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8294 to WFCORE-2415: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2415 (was: WFLY-8294) Component/s: Security (was: Security) > credential-reference must have defined combinations of constraints > ------------------------------------------------------------------ > > Key: WFCORE-2415 > URL: https://issues.jboss.org/browse/WFCORE-2415 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > credential-reference must have defined these combinations of constraints: > requires constraint: > ??alias "requires" [store], > ??store "requires" [alias] > alternatives constraint: > ??clear-text "alternatives" [store] > ??store "alternatives" [clear-text] > optional: type -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:27 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:27 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2413) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8313 to WFCORE-2413: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2413 (was: WFLY-8313) Component/s: Security (was: Security) > Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2413 > URL: https://issues.jboss.org/browse/WFCORE-2413 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Critical > > Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError. > I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError. > You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:28 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2416) Elytron properties-realm enforces REALM_NAME comment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7104 to WFCORE-2416: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2416 (was: WFLY-7104) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Elytron properties-realm enforces REALM_NAME comment > ---------------------------------------------------- > > Key: WFCORE-2416 > URL: https://issues.jboss.org/browse/WFCORE-2416 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Elytron enforces existence of {{"#$REALM_NAME=...$"}} comment in property file referenced from properties-realms. > When using legacy security and this line is missing, server starts without error. > *Expected behavior:* > Elytron's properties-realm *doesn't require* this comment. If the comment is present, it *may* verify if its content fits the realm name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:29 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2418) CS tool, invalid options are accepted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8196 to WFCORE-2418: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2418 (was: WFLY-8196) Component/s: Security (was: Security) > CS tool, invalid options are accepted > ------------------------------------- > > Key: WFCORE-2418 > URL: https://issues.jboss.org/browse/WFCORE-2418 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store, wildfly-elytron-tool > > Curently if I provide invalid option (e.g. --option_does_not_exists) it is accepted(ignored) and command is performed > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary --option_does_not_exists > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230"}) > {code} > It will be safer if command fail instead. It will guard users from unintentional command beeing performed. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary --option_does_not_exists > wildfly-elytron-tool: invalid option -- 'option_does_not_exists' > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:29 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2419) Complex type simple-permission-mapper in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7167 to WFCORE-2419: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2419 (was: WFLY-7167) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type simple-permission-mapper in Elytron subsystem > ---------------------------------------------------------- > > Key: WFCORE-2419 > URL: https://issues.jboss.org/browse/WFCORE-2419 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in simple-permission-mapper resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:29 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2421) CS tool generated different MASKED password then vault.sh In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8279 to WFCORE-2421: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2421 (was: WFLY-8279) Component/s: Security (was: Security) > CS tool generated different MASKED password then vault.sh > --------------------------------------------------------- > > Key: WFCORE-2421 > URL: https://issues.jboss.org/browse/WFCORE-2421 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > CS tool generated different MASKED password then vault.sh > When I run oldf vault.sh > {code} > ./vault.sh --keystore key.store --keystore-password secret_password --alias Vault --vault-block vaultBlock --attribute passDB --sec-attr secretvalue --enc-dir ./vault --iteration 230 --salt 12345678 -t > {code} > I can see this *MASK-1GhfMaq4jSY0.kFFU3QG4T* > Whole output: > {code:collapse=true} > > > > > > > > > {code} > In the other hand when I run new CS tool with params: > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret secretpassword --location="test.store1" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password secret_password --summary --salt 12345678 --iteration 230 --create > {code} > I get *MASK-KAwLfD1BN8WFhZptWsa17G* > Whole output: > {code:collapse=true} > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-KAwLfD1BN8WFhZptWsa17G==;12345678;230"}) > {code} > *I set these values for both:* > password to mask *secret_password* > iteration *12345678* > salt *230* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:28 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2417) Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7590 to WFCORE-2417: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2417 (was: WFLY-7590) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Inconsistency in attribute name of Elytron name-rewriter/final-name-rewriter > ---------------------------------------------------------------------------- > > Key: WFCORE-2417 > URL: https://issues.jboss.org/browse/WFCORE-2417 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > In Elytron subsystem there are attributes {{name-rewriter}} and {{final-name-rewriter}} which serves for the same purpose. Both of them are used for final name rewriting. It can be confusing when two different names are used for the same type of attribute. > Attribute {{name-rewriter}} is used in: > * {{realms}} attribute in {{security-domain}} > Attribute {{final-name-rewriter}} is used in: > * {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}} > * {{mechanism-realm-configurations}} in {{mechanism-configurations}} in both {{http-authentication-factory}} and {{sasl-authentication-factory}} > Names of {{name-rewriter}} and {{final-name-rewriter}} should be unified for this resources in DMR and also in XSD. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:29 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2420) JMS client dependencies doesn't contain a default wildfly-config.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7999 to WFCORE-2420: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2420 (was: WFLY-7999) Component/s: Security Security (was: JMS) (was: Security) > JMS client dependencies doesn't contain a default wildfly-config.xml > -------------------------------------------------------------------- > > Key: WFCORE-2420 > URL: https://issues.jboss.org/browse/WFCORE-2420 > Project: WildFly Core > Issue Type: Bug > Components: Security, Security > Reporter: Josef Cacek > Assignee: Jeff Mesnil > Priority: Critical > > Using the {{wildfly-jms-client-bom}} dependency for JMS clients doesn't introduce a default {{wildfly-config.xml}} with Elytron client configuration. As the result, clients are not able to authenticate (e.g. using JBOSS-LOCAL-USER SASL mechanism). > The default configuration in {{wildfly-config.xml}} should allow similar behavior as with legacy security. So the following call should pass: > {code} > ConnectionFactory connectionFactory = (ConnectionFactory) namingContext.lookup("jms/RemoteConnectionFactory"); > {code} > Currently the call throws exception: > {code} > SEVERE: Naming problem occured > javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server are supported] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:91) > at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:78) > at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:64) > at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123) > at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.wildfly.security.elytron.demo.JmsClient.main(JmsClient.java:45) > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:412) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:239) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466) > at org.jboss.remoting3.FutureConnection.connect(FutureConnection.java:113) > at org.jboss.remoting3.FutureConnection.init(FutureConnection.java:75) > at org.jboss.remoting3.FutureConnection.get(FutureConnection.java:151) > at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:422) > at org.jboss.remoting3.UncloseableEndpoint.getConnection(UncloseableEndpoint.java:57) > at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:105) > at org.wildfly.naming.client.remote.RemoteNamingProvider.lambda$new$0(RemoteNamingProvider.java:68) > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentity(RemoteNamingProvider.java:126) > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:108) > ... 7 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:30 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2422) Credential Store alias name in camel case leads to AssertionError. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7984 to WFCORE-2422: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2422 (was: WFLY-7984) Component/s: Security (was: Security) > Credential Store alias name in camel case leads to AssertionError. > ------------------------------------------------------------------ > > Key: WFCORE-2422 > URL: https://issues.jboss.org/browse/WFCORE-2422 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > Credential Store alias name in camel case leads to AssertionError. > I am not able to reproduce it over jboss-cli but I can reproduce it in tests. > You can see to attachment. > *How to reproduce* > * unzip uppercasealias.zip to wildfly/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/credential/store > * cd wildfly/testsuite/integration/basic > * mvn test -Dtest=CredentialStoreTestCase > In log you can see this: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "testCamelCase"), > ("alias" => "camelcasenotationalias") > ]): java.lang.AssertionError > at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:87) > at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:99) > at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1841) > at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1739) > at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1698) > at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:575) > at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:270) > at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146) > at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.execute(CredentialStoreAliasDefinition.java:209) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1390) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:419) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:240) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:240) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:30 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2423) Elytron resources runtime updates without reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7512 to WFCORE-2423: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2423 (was: WFLY-7512) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron resources runtime updates without reload > ------------------------------------------------ > > Key: WFCORE-2423 > URL: https://issues.jboss.org/browse/WFCORE-2423 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Dmitrii Tikhomirov > > When updating elytron resources, server ends up in {{reload-required}} state. For example > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Make it possible for all (most - some may be impossible) resources to support runtime updates. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:30 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2424) Updating of elytron kerberos security factory requires reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7342 to WFCORE-2424: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2424 (was: WFLY-7342) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Updating of elytron kerberos security factory requires reload > ------------------------------------------------------------- > > Key: WFCORE-2424 > URL: https://issues.jboss.org/browse/WFCORE-2424 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: user_experience > > Is it necessary? I mean adding kerberos-security-factory does not require reload. > It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime, > mechanism-oids, path, relative-to, server. For example > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:30 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2425) Allow expressions in credential-reference attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7863 to WFCORE-2425: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2425 (was: WFLY-7863) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Allow expressions in credential-reference attributes > ---------------------------------------------------- > > Key: WFCORE-2425 > URL: https://issues.jboss.org/browse/WFCORE-2425 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Labels: user_experience > > Change these attributes to {{"expressions-allowed" => true}} > {code} > These applies to key-store and key-manager: > */credential-reference/alias > */credential-reference/type > */credential-reference/clear-text > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:31 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2426) Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7492 to WFCORE-2426: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2426 (was: WFLY-7492) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Value of parameter "restart-required" for some attributes in Elytron subsystem resources does not match reality > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2426 > URL: https://issues.jboss.org/browse/WFCORE-2426 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Some attributes of some resources in {{elytron}} subsystem defines in its description that there is not necessary to do {{reload}} or {{restart}}. But reality is different. Trying to change such attributes you are informed that {{reload}} is necessary: > {noformat} > configurable-sasl-server-factory/filters > configurable-sasl-server-factory/properties > custom-role-mapper/* > aggregate-http-server-mechanism-factory/http-server-factories > constant-permission-mapper/permissions > filesystem-realm/levels > filesystem-realm/name-rewriter > ldap-key-store/attributes/new-item-template > service-loader-http-server-mechanism-factory/module > aggregate-principal-decoder/principal-decoders > simple-permission-mapper/permission-mappings > chained-name-rewriter/name-rewriters > custom-permission-mapper/* > configurable-http-server-mechanism-factory/properties > custom-name-rewriter/* > aggregate-sasl-server-factory/sasl-server-factories > aggregate-name-rewriter/name-rewriters > ldap-realm/identity-mapping/* > mechanism-provider-filtering-sasl-server-factory/filters > custom-principal-decoder/* > custom-realm-mapper/* > jdbc-realm/principal-query > key-managers/credential-reference > service-loader-sasl-server-factory/module > concatenating-principal-decoder/principal-decoders > credential-store/alias/* > custom-modifiable-realm/* > custom-credential-security-factory/* > key-store/credential-reference > custom-role-decoder/* > aggregate-role-mapper/role-mappers > custom-realm/* > {noformat} > The attributes are defined as {{"restart-required" => "no-services"}}, see e.g. {{/subsystem=elytron/concatenating-principal-decoder=concatPrincDecoder:read-resource-description}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:31 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2427) Credential store has configuration in "uri" attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7483 to WFCORE-2427: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2427 (was: WFLY-7483) Component/s: Security (was: Security) > Credential store has configuration in "uri" attribute. > ------------------------------------------------------ > > Key: WFCORE-2427 > URL: https://issues.jboss.org/browse/WFCORE-2427 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Priority: Critical > > Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo) > In my opinion the main intention for it is to have general solution for custom implementation. > *Current state* > {code} > /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true") > {code} > *Suggestion for improvement:* > Better solution to achieve this could be use a map. > e.g. some like that: > {code} > /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file}) > {code} > Now credential store name is in URI too, it can be get from resource name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:31 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2428) Properties of Elytron dir-context are parsed incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8167 to WFCORE-2428: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2428 (was: WFLY-8167) Component/s: Security (was: Security) > Properties of Elytron dir-context are parsed incorrectly > -------------------------------------------------------- > > Key: WFCORE-2428 > URL: https://issues.jboss.org/browse/WFCORE-2428 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Properties added for Elytron {{dir-context}} through server configuration are parsed incorrectly. In case when some value is used in server configuration then its representation in server obtains also quotation marks, i.e. {{something}} is parsed as string {{"something"}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:32 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2429) CLI command for update CredentialReference should fail rather then pass. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7907 to WFCORE-2429: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2429 (was: WFLY-7907) Component/s: Security (was: Security) > CLI command for update CredentialReference should fail rather then pass. > ------------------------------------------------------------------------ > > Key: WFCORE-2429 > URL: https://issues.jboss.org/browse/WFCORE-2429 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > CLI command for update CredentialReference should fail rather then pass. > Because CLI command doesn't persist any data to configuration file but pass. > I expect that command would fail and shows some error message. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=credS004:add(uri="cr-store://test/credS004.jceks?create.storage=true", credential-reference={clear-text=pass987}, relative-to=jboss.server.data.dir) > {code} > {code} > /subsystem=elytron/credential-store=credS004:write-attribute(name=credential-reference.store, value=credS002) > {code} > *AND* > {code} > /subsystem=elytron/credential-store=credS004:write-attribute(name=credential-reference.alias, value=credS002) > {code} > *Ends with success, but it has to be a failure* > These commands could lead to inconsistency. > Because there is valid state to have > credential-reference={clear-text=pass987} > and credential-reference={store=cs, alias=alias} > but not their combination. > *I can use this right form of command* > {code} > /subsystem=elytron/credential-store=credS004:write-attribute(name=credential-reference, value={store=credS002, alias=jimmy}) > {code} > Now is everything OK. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:32 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2430) Logging the elytron version once is sufficient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7976 to WFCORE-2430: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2430 (was: WFLY-7976) Component/s: Security (was: Security) > Logging the elytron version once is sufficient > ---------------------------------------------- > > Key: WFCORE-2430 > URL: https://issues.jboss.org/browse/WFCORE-2430 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Priority: Minor > > Pick one or the other please: > {code} > 19:05:58,886 INFO [org.wildfly.security] (ServerService Thread Pool -- 7) ELY00001: WildFly Elytron version 1.1.0.Beta21 > 19:05:58,890 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 7) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21, Subsystem Version=1.0.0.Beta2 > {code} > I couldn't care less about the Subsystem Version. Besides the extension code MUST get integrated into WildFly (Core) proper. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:32 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2431) Complex type configurable-sasl-server-factory in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7169 to WFCORE-2431: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2431 (was: WFLY-7169) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type configurable-sasl-server-factory in Elytron subsystem > ------------------------------------------------------------------ > > Key: WFCORE-2431 > URL: https://issues.jboss.org/browse/WFCORE-2431 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in configurable-sasl-server-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:32 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2432) Elytron auth method misconfiguration not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7698 to WFCORE-2432: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2432 (was: WFLY-7698) Component/s: Security (was: Security) > Elytron auth method misconfiguration not logged > ----------------------------------------------- > > Key: WFCORE-2432 > URL: https://issues.jboss.org/browse/WFCORE-2432 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Priority: Critical > Labels: user_experience > > When deployment is configured to be secured with DIGEST, but {{http-authentication-factory}} does not list DIGEST mechanism, user is not informed about misconfiguration. Even when TRACE logging is turned on. When user tries to access app 403 http code is returned and Forbidden is shown in browser. I would expect browser dialog to appear to allow user provide credentials (401 http status code). > {code:title=web.xml} > > DIGEST > ApplicaitonRealm > > {code} > {code:title=standalone-elytron.xml} > > > > > > > > > {code} > This applies globally to all authentication mechanisms, not only DIGEST. > Could elytron handle misconfiguration: > * either fail during deploying application as deployment requirement can't be satisfy > * or provide reasonable elytron defaults of missing mechanism configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:32 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2433) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8022 to WFCORE-2433: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2433 (was: WFLY-8022) Component/s: Security (was: Security) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2433 > URL: https://issues.jboss.org/browse/WFCORE-2433 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:33 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2435) Elytron missing constant-role-decoder In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7596 to WFCORE-2435: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2435 (was: WFLY-7596) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron missing constant-role-decoder > ------------------------------------- > > Key: WFCORE-2435 > URL: https://issues.jboss.org/browse/WFCORE-2435 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > > There is no {{constant-role-decoder}}, however all of other mappers have constant-* variant: > {code} > [standalone at localhost:9990 /] /subsystem=elytron/constant- > constant-name-rewriter constant-permission-mapper constant-principal-decoder constant-realm-mapper constant-role-mapper > {code} > It can be useful for simple applications / demos / testing ... > Please add it for the sake of completeness. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:33 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2434) Elytron, log cause of LoginException during obraining ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8286 to WFCORE-2434: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2434 (was: WFLY-8286) Component/s: Security (was: Security) > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFCORE-2434 > URL: https://issues.jboss.org/browse/WFCORE-2434 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: David Lloyd > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:34 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2436) Complex type security-domain in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7171 to WFCORE-2436: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2436 (was: WFLY-7171) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type security-domain in Elytron subsystem > ------------------------------------------------- > > Key: WFCORE-2436 > URL: https://issues.jboss.org/browse/WFCORE-2436 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in security-domain resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:34 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2437) Elytron Http status code for missing LoginPermission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7393 to WFCORE-2437: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2437 (was: WFLY-7393) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron Http status code for missing LoginPermission > ---------------------------------------------------- > > Key: WFCORE-2437 > URL: https://issues.jboss.org/browse/WFCORE-2437 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Optional > > Lack of {{LoginPermission}} leads to 401 http code. Which could IMO indicate user can try to login again with different password. However it won't help in this case. I wonder, wouldn't 403 Forbidden be more suitable here? Indicating user authentication passed, but user is missing some permission. > Setting with low priority as in DR7 in default configuration LoginPermission is added by default. > David: "I think you may be right @MartinChoma - 401 is called "unauthorized" but really it should say "authentication required" 403 is the correct response for an authorization error" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:34 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2438) Legacy Kerberos for management interface returns 500 instead of 401 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7989 to WFCORE-2438: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2438 (was: WFLY-7989) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Legacy Kerberos for management interface returns 500 instead of 401 > ------------------------------------------------------------------- > > Key: WFCORE-2438 > URL: https://issues.jboss.org/browse/WFCORE-2438 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 4.0.0.Alpha1 > > > On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case. > Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages > {code:title=server.log} > 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:35 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2439) Complex type configurable-http-server-mechanism-factory in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7165 to WFCORE-2439: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2439 (was: WFLY-7165) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type configurable-http-server-mechanism-factory in Elytron subsystem > ---------------------------------------------------------------------------- > > Key: WFCORE-2439 > URL: https://issues.jboss.org/browse/WFCORE-2439 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type configurable-http-server-mechanism-factory which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:35 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2440) CS tool, 2 places to specify credential store location In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8177 to WFCORE-2440: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2440 (was: WFLY-8177) Component/s: Security (was: Security) > CS tool, 2 places to specify credential store location > ------------------------------------------------------ > > Key: WFCORE-2440 > URL: https://issues.jboss.org/browse/WFCORE-2440 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > Currently there are 2 places, where location can be specified: > - URI parameter > - location parameter > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230 > {code} > Choose one. In case SPI dictates that, revise SPI. > Setting to high priotity, as possible it is problem of SPI. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:35 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2441) Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7679 to WFCORE-2441: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2441 (was: WFLY-7679) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper > ------------------------------------------------------------------------------------ > > Key: WFCORE-2441 > URL: https://issues.jboss.org/browse/WFCORE-2441 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > There are inconsistencies between DMR and XSD representation of {{constant-permission-mapper}}. > According to XSD {{permission}} must occur at least one times in {{constant-permission-mapper}}. According to DMR it is {{"nillable" => true}}. This should be unified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:35 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2442) Incorrect realm for DIGEST-MD5 when Elytron SASL global factory is directly used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8193 to WFCORE-2442: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2442 (was: WFLY-8193) Component/s: Security (was: Security) > Incorrect realm for DIGEST-MD5 when Elytron SASL global factory is directly used > -------------------------------------------------------------------------------- > > Key: WFCORE-2442 > URL: https://issues.jboss.org/browse/WFCORE-2442 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > > In case when some sasl-authentication-factory, which uses directly sasl-server-factory="global", is used for authentication and DIGEST-MD5 mechanism is used, then authentication fails. It is caused by incorrectly passed realm name used for authentication. See Steps to Reproduce for more details. > Following is used for creating DIGEST-MD5 for authentication response (realm "localhost" is not correct used realm): > {code} > charset=utf-8,username="user1",realm="localhost",nonce="N7K8/KwSm/p8dxOK2LgcCBDPrhva3ILhHLQ4qWXO",nc=00000001,cnonce="MVJ6zYGtLDjffNPgt+l7OKXq62o1vu/QkPooB1EyCBxK6JiG",digest-uri="remote/localhost",maxbuf=65536,response=3acb12f0e1f42edc48e13cac8e77ae2e,qop=auth > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:36 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2443) Wrong description of Elytron configurable-sasl-server-factory in management model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7448 to WFCORE-2443: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2443 (was: WFLY-7448) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Wrong description of Elytron configurable-sasl-server-factory in management model > --------------------------------------------------------------------------------- > > Key: WFCORE-2443 > URL: https://issues.jboss.org/browse/WFCORE-2443 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Description of {{configurable-sasl-server-factory}} resource in CLI is incorrectly copied from {{aggregate-sasl-server-factory}}. It says "description" => "A sasl server factory definition where the sasl server factory is an aggregation of other sasl server factories.". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:36 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2444) There isn't possibility log in to management web console as user which was dynamically added after EAP was started. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7939 to WFCORE-2444: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2444 (was: WFLY-7939) Component/s: Security (was: Security) > There isn't possibility log in to management web console as user which was dynamically added after EAP was started. > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2444 > URL: https://issues.jboss.org/browse/WFCORE-2444 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > I am not able to log in to management web console as user which was dynamically added after EAP was started. > *Scenario:* > * EAP is running - *standalone.sh -c=standalone-elytron.xml* > * add user through script *add-user.sh -u john -p password1! -s* > * log in to management web console as user *john* > *Result:* > * It doesn't work until restart > When we use Picketbox then it works fine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:36 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2445) Wrong documentation of Elytron configurable-http-server-mechanism-factory properties element in XSD In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7450 to WFCORE-2445: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2445 (was: WFLY-7450) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Wrong documentation of Elytron configurable-http-server-mechanism-factory properties element in XSD > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-2445 > URL: https://issues.jboss.org/browse/WFCORE-2445 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Documentation of element {{properties}} for {{configurable-http-server-mechanism-factory}} (httpServerMechanismFactoryType) in wildfly-elytron_1_0.xsd says: "Additional properties that should be passed to the factor for SASL mechanism detection and creation.". However it should be HTTP mechanism instead of SASL. There is also typo "factor", it should be "factory". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:36 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2446) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7624 to WFCORE-2446: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2446 (was: WFLY-7624) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2446 > URL: https://issues.jboss.org/browse/WFCORE-2446 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > There are inconsistencies between DMR and XSD representation of {{key-managers}} and {{trust-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:37 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2447) Wrong description of Elytron configurable-http-server-mechanism-factory in management model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7449 to WFCORE-2447: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2447 (was: WFLY-7449) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Wrong description of Elytron configurable-http-server-mechanism-factory in management model > ------------------------------------------------------------------------------------------- > > Key: WFCORE-2447 > URL: https://issues.jboss.org/browse/WFCORE-2447 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Description of {{configurable-http-server-mechanism-factory}} resource is incorrectly copied from {{aggregate-sasl-server-factory}}. It said "description" => "A sasl server factory definition where the sasl server factory is an aggregation of other sasl server factories.". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:37 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2448) Setting elytron ssl-context on undertow without reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7329 to WFCORE-2448: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2448 (was: WFLY-7329) Component/s: Security Security (was: Security) (was: Web (Undertow)) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Setting elytron ssl-context on undertow without reload > ------------------------------------------------------ > > Key: WFCORE-2448 > URL: https://issues.jboss.org/browse/WFCORE-2448 > Project: WildFly Core > Issue Type: Bug > Components: Security, Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Tomaz Cerar > Labels: user_experience > > Please, allow setting of elytron ssl-context on undertow without reload. > {code} > [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=server) > { > ????"outcome" => "success", > ????"response-headers" => { > ????????"operation-requires-reload" => true, > ????????"process-state" => "reload-required" > ????} > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:37 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2449) Default Elytron realm names are confusing - use same values as Legacy security realms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8000 to WFCORE-2449: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2449 (was: WFLY-8000) Component/s: Security (was: Security) > Default Elytron realm names are confusing - use same values as Legacy security realms > ------------------------------------------------------------------------------------- > > Key: WFCORE-2449 > URL: https://issues.jboss.org/browse/WFCORE-2449 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Labels: user_experience > > The default application server profiles now contain Elytron subsystem configured (more in EAP7-543). The subsystem contains 2 properties realms, which copy behavior of security realms in legacy security. They use the same name as the original ones *ApplicationRealm* and *ManagementRealm*: > {code:xml} > > > > > > > > > {code} > The new Elytron realms must use different names than legacy ones. Otherwise customers/administrators may think about the Elytron realms as just references to the legacy security. > *Suggested solution* > Rename the default Elytron realms to something like *ElytronManagementRealm* or *ManagementElytronRealm*. So the configuration looks like: > {code:xml} > > > > > > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:38 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2451) CS tool, invalid content of --type parameter leads to NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8200 to WFCORE-2451: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2451 (was: WFLY-8200) Component/s: Security (was: Security) > CS tool, invalid content of --type parameter leads to NPE > --------------------------------------------------------- > > Key: WFCORE-2451 > URL: https://issues.jboss.org/browse/WFCORE-2451 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > If I fill --type option with some invalid value (other then KeyStoreCredentialStore) I get NPE. For example with -t DoesNotExists I get > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary -t DoesNotExists > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:38 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2450) Definition Credential Store with existing storage file but with wrong key password causes ugly failure-description. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7479 to WFCORE-2450: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2450 (was: WFLY-7479) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Definition Credential Store with existing storage file but with wrong key password causes ugly failure-description. > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2450 > URL: https://issues.jboss.org/browse/WFCORE-2450 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Definition Credential Store with existing storage file but with wrong key password causes ugly failure-description. > *How to reproduce* > Prepare credential store file (the easiest way is create credential store from scratch) > /subsystem=elytron/credential-store=cs_pass123:add(uri="cr-store://test/cs/ks-pass123.jceks?store.password=pass123;create.storage=true") > /subsystem=elytron/credential-store=cs_pass123/alias=dbPass:add(secret-value=passwordToDB) > Then I try to create Credential store with wrong key password to existing store file. > /subsystem=elytron/credential-store=cs_wrong_key_pass:add(uri="cr-store://test/cs/ks-pass123.jceks?store.password=pass123;key.password=pass456") > *I can see this result:* > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store-client.cs_wrong_key_pass" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store-client.cs_wrong_key_pass: WFLYELY00004: Unable to start the service. > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09506: Cannot read credential storage file '/home/hsvabek/securityworkspace/VERIFICATION/2016_11_02_UX_testing/jboss-eap-7.1.0.DR7/standalone/data/cs/ks-pass123.jceks' for the store named 'cs_wrong_key_pass' > Caused by: java.security.UnrecoverableKeyException: Given final block not properly padded"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.cs_wrong_key_pass"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > *Suggestion for solution* > failure-description must not contain Exception or snippet stacktrace. > Description like that "Password for credential store key is incorrect." -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:38 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2452) Elytron key-store requires set credential-reference which is wrongly marked as optional. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7629 to WFCORE-2452: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2452 (was: WFLY-7629) Component/s: Security (was: Security) > Elytron key-store requires set credential-reference which is wrongly marked as optional. > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2452 > URL: https://issues.jboss.org/browse/WFCORE-2452 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > In EAP7.1.0.DR7 Elytron key-store uses credential-reference with clear-text attribute for password instead of password attribute. > But there is problem with credential-reference element which is wrongly marked as optional. > Please set this element on mandatory with respect to this issue https://issues.jboss.org/browse/WFLY-7125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:39 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2456) Obtain password from external source (CMD, EXT) doesn't work on Windows. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8268 to WFCORE-2456: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2456 (was: WFLY-8268) Component/s: Security (was: Security) > Obtain password from external source (CMD, EXT) doesn't work on Windows. > ------------------------------------------------------------------------ > > Key: WFCORE-2456 > URL: https://issues.jboss.org/browse/WFCORE-2456 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Obtain password from external source (CMD, EXT) doesn't work on Windows. > Try to create new CS which obtains password from external source: > {code} > /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) > {code} > pass.bat file contains only this > {code} > echo %1 > {code} > Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: > Add new alias to CS -> JCEKS file is created > Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. > In my opinion there is problem with back slashes in script path. > https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 > Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:39 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2455) Empty secret-value is not allowed in credential stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8143 to WFCORE-2455: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2455 (was: WFLY-8143) Component/s: Security (was: Security) > Empty secret-value is not allowed in credential stores > ------------------------------------------------------- > > Key: WFCORE-2455 > URL: https://issues.jboss.org/browse/WFCORE-2455 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store > > It's not possible to add an entry with empty secret-value into a credential store. > Masking the fact the password is empty is a valid scenario. > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0155: 'secret-value' may not be null", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add(secret-value="") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter secret-value. Values must have a minimum length of 1 characters", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:39 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2454) Complex type ldap-realm in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7173 to WFCORE-2454: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2454 (was: WFLY-7173) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type ldap-realm in Elytron subsystem > -------------------------------------------- > > Key: WFCORE-2454 > URL: https://issues.jboss.org/browse/WFCORE-2454 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in ldap-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:38 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2453) Complicated failure-descriptions in Elytron simple-permission-mapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7475 to WFCORE-2453: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2453 (was: WFLY-7475) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complicated failure-descriptions in Elytron simple-permission-mapper > -------------------------------------------------------------------- > > Key: WFCORE-2453 > URL: https://issues.jboss.org/browse/WFCORE-2453 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > There are complicated failure-descriptions in Elytron simple-permission-mapper. They include some details from exceptions which are not needed and can be confused for non-java administrators. Please handle these exceptions and provide some user friendly failure-description. > Examples of complicated failure-description in simple-permission-mapper: > * Wrong name of permission class: > {code} > /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.WrongLoginPermission,target-name=someName}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [org.wildfly.security.auth.permission.WrongLoginPermission]. > Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"org.wildfly.security.auth.permission.WrongLoginPermission\" > Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.permission.WrongLoginPermission from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/uxcli/jboss-eap-7.1/modules/system/layers/base))]"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > * Adding permission, but non existing module is used: > {code} > /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.LoginPermission,target-name=someName,module=some.nonexist.module}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main > Caused by: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > Suggestion for improvement: > * use only description of failure, e.g. something like "module a.b.c. does not exist" > * do not use any unneeded information - e.g. "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:40 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2457) Insufficient failure-description for filters of Elytron configurable-sasl-server-factory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7452 to WFCORE-2457: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2457 (was: WFLY-7452) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Insufficient failure-description for filters of Elytron configurable-sasl-server-factory > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2457 > URL: https://issues.jboss.org/browse/WFCORE-2457 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when both {{pattern-filter}} and {{predefined-filter}} are set in one Object in CLI command for {{filters}} of Elytron {{configurable-sasl-server-factory}} then it finishes with insufficient failure-description: > {code} > /subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}]) > { > "outcome" => "failed", > "failure-description" => "WFLYELY01014: Invalid [filters] definition.", > "rolled-back" => true > } > {code} > This failure-description is not wrong but it is also not helpful. Improve failure-description to say that only one of {{pattern-filter}} and {{predefined-filter}} can be set in one Object in list of filters. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:40 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2458) Inconsistent attribute desription of security domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7686 to WFCORE-2458: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2458 (was: WFLY-7686) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 10.1.0.Final) > Inconsistent attribute desription of security domain > ---------------------------------------------------- > > Key: WFCORE-2458 > URL: https://issues.jboss.org/browse/WFCORE-2458 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Juraj Dur?ni > Assignee: Darran Lofthouse > Priority: Minor > > Some attributes have inconsistent description (obtained using 'read-resource-description' operation): > - Missing module attribute: > {code:plain|title=Missing module attribute} > [standalone at localhost:9990 /] /subsystem=security/security-domain=other/mapping=classic:read-resource-description > { > "outcome" => "success", > "result" => { > "description" => "Mapping configuration. Configures a list of mapping modules to be used for principal, role, attribute and credential mapping.", > "deprecated" => { > "since" => "1.3.0", > "reason" => "The Security subsystem is deprecated and may be removed, significantly revised, or limited to managed domain legacy server use in future versions." > }, > "access-constraints" => { > "sensitive" => {"security-domain" => {"type" => "core"}}, > "application" => {"security-domain" => {"type" => "security"}} > }, > "attributes" => {"mapping-modules" => { > "type" => LIST, > "description" => "List of modules that map principal, role, and credential information", > "expressions-allowed" => false, > "nillable" => true, > "deprecated" => { > "since" => "1.2.0", > "reason" => "Use of this attribute is deprecated, use resource" > }, > "value-type" => { > "code" => { > "description" => "Class name of the module to be instantiated.", > "type" => STRING, > "nillable" => false, > "min-length" => 1 > }, > "type" => { > "description" => "Type of mapping this module performs. Allowed values are principal, role, attribute or credential..", > "type" => STRING, > "nillable" => false > }, > "module-options" => { > "description" => "List of module options containing a name/value pair.", > "type" => OBJECT, > "value-type" => STRING, > "nillable" => true > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }}, > "operations" => undefined, > "notifications" => undefined, > "children" => {"mapping-module" => { > "description" => "List of modules that map principal, role, and credential information", > "model-description" => undefined > }} > } > } > {code} > - Module description in policy-module refers to "login module" > {code:plain|title=Inaccurate description} > [standalone at localhost:9990 /] /subsystem=security/security-domain=other/authorization=classic/policy-module=a:read-resource-description > { > "outcome" => "success", > "result" => { > "description" => "List of authentication modules", > "access-constraints" => { > "sensitive" => {"security-domain" => {"type" => "core"}}, > "application" => {"security-domain" => {"type" => "security"}} > }, > "attributes" => { > "code" => { > "type" => STRING, > "description" => "Class name of the module to be instantiated.", > "expressions-allowed" => false, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "flag" => { > "type" => STRING, > "description" => "The flag controls how the module participates in the overall procedure. Allowed values are requisite, required, sufficient or optional.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "required", > "requisite", > "sufficient", > "optional" > ], > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "module" => { > "type" => STRING, > "description" => "Name of JBoss Module where the login module is located.", > "expressions-allowed" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "module-options" => { > "type" => OBJECT, > "description" => "List of module options containing a name/value pair.", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > } > }, > "operations" => undefined, > "notifications" => undefined, > "children" => {} > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:16 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:16 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2364) User should be able to specify only one password mapper in jdbc-realm resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7287 to WFCORE-2364: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2364 (was: WFLY-7287) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > User should be able to specify only one password mapper in jdbc-realm resource > ------------------------------------------------------------------------------ > > Key: WFCORE-2364 > URL: https://issues.jboss.org/browse/WFCORE-2364 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Pedro Igor > Priority: Minor > Labels: user_experience > > It is possible to specify in {{principal-query}} all of {{clear-password-mapper}}, {{bcrypt-mapper}}, {{simple-digest-mapper}}, {{salted-simple-digest-mapper}}, {{scram-mapper}} at one moment. But, in fact, specifying only one mapper per principal query make sense. Change model/subsystem , that only adding on password mapper at a moment is allowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:41 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2459) Missing log that authetication failed in Elytron LdapRealm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8165 to WFCORE-2459: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2459 (was: WFLY-8165) Component/s: Security (was: Security) > Missing log that authetication failed in Elytron LdapRealm > ---------------------------------------------------------- > > Key: WFCORE-2459 > URL: https://issues.jboss.org/browse/WFCORE-2459 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when wrong password is passed during authentication through LdapRealm then server log does not include information that 'authentication failed'. > Following log occurs in server.log: > {code} > 2017-02-20 13:16:41,482 DEBUG [org.wildfly.security] (default task-2) Trying to create identity for principal [jduke]. > 2017-02-20 13:16:41,483 DEBUG [org.wildfly.security] (default task-2) Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@3e8a4972]. Returning attributes are [[userPassword]]. Binary attributes are [[]]. > 2017-02-20 13:16:41,491 DEBUG [org.wildfly.security] (default task-2) Found entry [uid=jduke,ou=People,dc=jboss,dc=org]. > 2017-02-20 13:16:41,493 DEBUG [org.wildfly.security] (default task-2) Identity for principal [jduke] found at [uid=jduke,ou=People,dc=jboss,dc=org]. > 2017-02-20 13:16:41,504 DEBUG [org.wildfly.security] (default task-2) Context [javax.naming.ldap.InitialLdapContext at 3db0aa06] was closed. Connection closed or just returned to the pool. > 2017-02-20 13:16:41,506 DEBUG [org.wildfly.security] (default task-2) User jduke authorization failed. > 2017-02-20 13:16:41,506 TRACE [org.wildfly.security] (default task-2) Handling AuthenticationCompleteCallback: fail > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:41 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2460) Connection pool in Elytron dir-context is not configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7845 to WFCORE-2460: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2460 (was: WFLY-7845) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Connection pool in Elytron dir-context is not configurable > ---------------------------------------------------------- > > Key: WFCORE-2460 > URL: https://issues.jboss.org/browse/WFCORE-2460 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron dir-context resource allows to configure connection pool through its {{enable-connection-pooling}} attribute. However another options for connection pool is not able to be set in application server configuration. It means that connection pool can be used but cannot be parametrized. See [1] for another Java connection pool options. > [1] http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/config.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:41 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2461) Credential-store attribute relative-to doesn't reference path as required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8068 to WFCORE-2461: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2461 (was: WFLY-8068) Component/s: Security (was: Security) > Credential-store attribute relative-to doesn't reference path as required > ------------------------------------------------------------------------- > > Key: WFCORE-2461 > URL: https://issues.jboss.org/browse/WFCORE-2461 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ilia Vassilev > > Combination of {{path}} and {{relative-to}} attributes is common across all the elytron subsystem. All but one {{relative-to}} attributes list the "path" as required: > {code} > "relative-to" => { > "type" => STRING, > ... > "requires" => ["path"], > ... > } > {code} > The credential-store configuration doesn't define this dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:41 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2462) CS tool, format Missing required option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8202 to WFCORE-2462: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2462 (was: WFLY-8202) Component/s: Security (was: Security) > CS tool, format Missing required option > --------------------------------------- > > Key: WFCORE-2462 > URL: https://issues.jboss.org/browse/WFCORE-2462 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma at localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:42 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2465) Elytron key-manager for server-ssl-context is not required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7652 to WFCORE-2465: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2465 (was: WFLY-7652) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron key-manager for server-ssl-context is not required > ---------------------------------------------------------- > > Key: WFCORE-2465 > URL: https://issues.jboss.org/browse/WFCORE-2465 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > > It is possible to create server ssl context without key manager. > {code} > /subsystem=elytron/server-ssl-context=a:add() > {code} > Key manager in elytron holds reference to key store. > I can't think of use case where it would be usefull to configure server ssl context without specifying key store. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:42 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2463) Configuring more password types should be allowed for Elytron filesystem-realm identity in management model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7584 to WFCORE-2463: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2463 (was: WFLY-7584) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Configuring more password types should be allowed for Elytron filesystem-realm identity in management model > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2463 > URL: https://issues.jboss.org/browse/WFCORE-2463 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when two password type are part of {{set-password}} operation for identity of Elytron filesystem-realm then only first of them is used and others are discarded. Configuring multiple credentials for one identity should be supported [1]. > [1] https://issues.jboss.org/browse/WFLY-7584?focusedCommentId=13322919&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13322919 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:42 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2464) CS tool, Add possibility to produce masked password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8192 to WFCORE-2464: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2464 (was: WFLY-8192) Component/s: Security (was: Security) > CS tool, Add possibility to produce masked password > --------------------------------------------------- > > Key: WFCORE-2464 > URL: https://issues.jboss.org/browse/WFCORE-2464 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: credential-store, user_experience > > This JIRA is requesting for specialized feature (option) of getting masked string. > Now you can get value of masked password, but as a side effect of adding alias into credential store and parameter --summary have to be used. > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230"}) > {code} > And in output there is masked string {{MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230}} hidden. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:43 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2468) Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7522 to WFCORE-2468: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2468 (was: WFLY-7522) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2468 > URL: https://issues.jboss.org/browse/WFCORE-2468 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception. > *Steps to reproduce* > * firefly.keystore which is attached copy to eap_home/standalone/data/cs. > * /subsystem=elytron/key-store=ff001:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {clear-text=Elytron}) > */subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001) > And you get this output: > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-managers.km002" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-managers.km002: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-managers.km002"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > There must be some kind of information about missing credential-reference or at least missing (wrong) password to key-store. > When I add there credential-reference with pass to Key-store then operation passes > /subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001, credential-reference={clear-text=Elytron}) > *Suggestions to improvement* > failure-description must not contain Exception or snippet stacktrace. > Please replace WFLYCTL0080 part to better message. > e.g. "credential-reference is required", "Missing password to key-store access" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:42 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2466) Elytron, IBM java, SPNEGO continuation required situation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7875 to WFCORE-2466: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2466 (was: WFLY-7875) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Elytron, IBM java, SPNEGO continuation required situation > --------------------------------------------------------- > > Key: WFCORE-2466 > URL: https://issues.jboss.org/browse/WFCORE-2466 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: ContinuationRequiredIBM.pcap, server.log > > > I have problem to achieve this scenario with elytron on IBM java: > # Using IBM Java > # Client sends non kerberos OID mechanism as most preferred with non kerberos ticket > # Server response with "continuation required" > # Client sends kerberos ticket > # Server response with 401 instead of 200 > # In server there is error > {code} > 10:43:35,570 TRACE [org.wildfly.security] (default task-3) GSSContext message exchange failed: org.ietf.jgss.GSSException, major code: 10, minor code: 0 > major string: Defective token > minor string: Bad token tag: -95 > at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:5) > at com.ibm.security.jgss.TokenHeader.a(TokenHeader.java:33) > at com.ibm.security.jgss.TokenHeader.a(TokenHeader.java:102) > at com.ibm.security.jgss.TokenHeader.(TokenHeader.java:70) > at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:119) > at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:186) > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:138) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > {code} > Basically, it is same scenario as tested in [1] (for legacy security). > This scenario works correctly > * on Oracle and OpenJDK java with elytron in EAP 7.1 > * with legacy security on IBM java in EAP 7.1 > Setting high priority as: > * It works in legacy security, so customers won't be able to migrate > * Similar error was resolved in EAP 7.0 (JBEAP-3709) as blocker because customer case existed for that. > [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13db50ff43/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/negotiation/SPNEGOLoginModuleTestCase.java#L344 > [2] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13db50ff43/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/negotiation/SPNEGOLoginModuleTestCase.java#L357 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:42 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2467) Specify detailed HttpServerAuthenticationMechanismFactory interface contract In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7693 to WFCORE-2467: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2467 (was: WFLY-7693) Component/s: Security (was: Security) > Specify detailed HttpServerAuthenticationMechanismFactory interface contract > ---------------------------------------------------------------------------- > > Key: WFCORE-2467 > URL: https://issues.jboss.org/browse/WFCORE-2467 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Priority: Critical > > Please specify detailed contract of HttpServerAuthenticationMechanismFactory. > Describe which params are allowed to be null and what happens in that case. Also describe if null return values are allowed from interface methods and when does that could happen. > You can consider {{javax.security.sasl.SaslServerFactory}} as example of detailed contract. > For example: > * Is {{properties}} parameter of {{getMechanismNames()}} allowed to be null? > * is {{getMechanismNames()}} allowed to return null ? > * Are any of {{createAuthenticationMechanism()}} parameters allowed to be null? > ** For {{ServerMechanismFactoryImpl}} implementation {{properties}} could not be null - is it general rule? > {code} > java.lang.IllegalArgumentException: Parameter 'properties' may not be null > at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:69) > at org.wildfly.common.Assert.checkNotNullParam(Assert.java:47) > at org.wildfly.security.http.impl.ServerMechanismFactoryImpl.createAuthenticationMechanism(ServerMechanismFactoryImpl.java:79) > {code} > ** For {{ServerMechanismFactoryImpl}} implementation {{callbackHandler}} could not be null - is it general rule? > {code} > java.lang.IllegalArgumentException: Parameter 'callbackHandler' may not be null > at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:69) > at org.wildfly.common.Assert.checkNotNullParam(Assert.java:47) > at org.wildfly.security.http.impl.ServerMechanismFactoryImpl.createAuthenticationMechanism(ServerMechanismFactoryImpl.java:80) > {code} > ** For {{ServerMechanismFactoryImpl}} implementation {{mechanismName}} could not be null - is it general rule? > {code} > java.lang.IllegalArgumentException: Parameter 'mechanismName' may not be null > at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:69) > at org.wildfly.common.Assert.checkNotNullParam(Assert.java:47) > at org.wildfly.security.http.impl.ServerMechanismFactoryImpl.createAuthenticationMechanism(ServerMechanismFactoryImpl.java:78) > {code} > I would suggest to wrap {{java.lang.IllegalArgumentException}} to HttpAuthenticationException. Otherwise possibility of {{IllegalArgumentException}} should be documented in contract. > * Is {{createAuthenticationMechanism()}} allowed to return null? > Filing as Critical, as this interface is expected to be implemented by custom factories. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:44 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2472) Review security-property resource in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7181 to WFCORE-2472: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2472 (was: WFLY-7181) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Review security-property resource in Elytron subsystem > ------------------------------------------------------ > > Key: WFCORE-2472 > URL: https://issues.jboss.org/browse/WFCORE-2472 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 4.0.0.Alpha1 > > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:45 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2475) Changing Elytron default-authentication-context ends in reload-required state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8293 to WFCORE-2475: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2475 (was: WFLY-8293) Component/s: Security (was: Security) > Changing Elytron default-authentication-context ends in reload-required state > ----------------------------------------------------------------------------- > > Key: WFCORE-2475 > URL: https://issues.jboss.org/browse/WFCORE-2475 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > If I try to change Elytron default-authentication-context server ends in reload-required state. > {code} > /subsystem=elytron/authentication-context=auth-context:add() > /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model > {code} > /subsystem=elytron:read-resource-description(recursive=false) > { > ... > "default-authentication-context" => { > "type" => STRING, > "description" => "The default authentication context to be associated with all deployments.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.authentication-context", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > ... > } > {code} > According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary > no-services ? Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:46 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2477) Legacy Kerberos in management, regression in choosing keytab strategy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7991 to WFCORE-2477: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2477 (was: WFLY-7991) Component/s: Security (was: Security) > Legacy Kerberos in management, regression in choosing keytab strategy > --------------------------------------------------------------------- > > Key: WFCORE-2477 > URL: https://issues.jboss.org/browse/WFCORE-2477 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > There is regresion in strategy of choosing keytab described by xsd > {code:xml|title=wildfly-config_5_0.xsd} > > > > > Reference to an individual keytab. > On handling the authentication for an incoming request two pieces of information are known, the protocol and the name of the host > this server is acting as. For HTTP requests the protocol will always be HTTP, for requests over Remoting by default the protocol will > be 'remote' although this can be overridden. > At the time authentication is going to be handled the keytab will be selected as follows: - > 1 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching protocol/hostname. > 2 - Iterate the list of keytabs and identify one where the name of the principal matches matches protocol/hostname. > 3 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching hostname. > 4 - Iterate the list of keytabs and identify one where the hostname portion of the principal matches the hostname of the request. > 5 - Use the keytab where for-hosts is set to '*'. > If no match is found no keytab will be selected and Kerberos will not be available for communication as that host. > > > {code} > In this example > {code:xml|title=standalone.xlm} > > > > > > > {code} > Rule 1 should be applied, but {{}} is chosen, > {code:title=server.log} > 10:28:40,743 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:28:40,744 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 10:28:40,744 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,847 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:28:40,848 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > {code} > In this example > {code:xml|title=standalone.xlm} > > > > > > > {code} > Rule 2 should be applied, but {{}} is chosen > {code:title=server.log} > 10:29:21,889 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:29:21,890 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/wronghost at JBOSS.ORG' for host 'localhost.localdomain' > 10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/wronghost at JBOSS.ORG' for host 'localhost.localdomain' > 10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,959 INFO [stdout] (management task-9) Entered Krb5Context.acceptSecContext with state=STATE_NEW > 10:29:21,960 INFO [stdout] (management task-9) Looking for keys for: HTTP/wronghost at JBOSS.ORG > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:43 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2469) Complex type mechanism-provider-filtering-sasl-server-factory in Elytron subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7170 to WFCORE-2469: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2469 (was: WFLY-7170) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complex type mechanism-provider-filtering-sasl-server-factory in Elytron subsystem > ---------------------------------------------------------------------------------- > > Key: WFCORE-2469 > URL: https://issues.jboss.org/browse/WFCORE-2469 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > Elytron subsystem uses complex type in mechanism-provider-filtering-sasl-server-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:45 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2473) It is possible to create constant-name-rewriter without defined constant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7670 to WFCORE-2473: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2473 (was: WFLY-7670) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > It is possible to create constant-name-rewriter without defined constant > ------------------------------------------------------------------------ > > Key: WFCORE-2473 > URL: https://issues.jboss.org/browse/WFCORE-2473 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > If user adds a new {{constant-name-rewriter}} via following command {{/subsystem=elytron/constant-name-rewriter=name-rewriter:add(constant)}} then is a new rewriter created. > It shouldn't be possible since {{constant}} attribute isn't filled correctly. However, there is added a new rewriter with {{true}} value [1] instead. > [1] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:45 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2476) Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7578 to WFCORE-2476: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2476 (was: WFLY-7578) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR > --------------------------------------------------------------------- > > Key: WFCORE-2476 > URL: https://issues.jboss.org/browse/WFCORE-2476 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > *Issue description:* > In _wildfly-elytron_1_0.xsd_, a file type is represented inconsistently. There are {{basicFileType}} and {{fileType}} complex types used, but there are also {{path}} and {{relative-to}} attributes used ({{providerLoadersType}}, {{kerberosSecurityFactory}}). > In DMR, file is represented as object (e.g. {{properties-realm}}) or as attributes (e.g. {{filesystem-realm}}, {{key-store}}). > *Suggestions for improvement:* > The file representation should be consistent in XSD/DMR. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:47 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2482) Elytron key/trust-manager-factory default algorithm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7472 to WFCORE-2482: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2482 (was: WFLY-7472) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Elytron key/trust-manager-factory default algorithm > --------------------------------------------------- > > Key: WFCORE-2482 > URL: https://issues.jboss.org/browse/WFCORE-2482 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > {{key-manager-factory}} and {{trust-manager-factory}} requires user to specify algorithm. > Consider defaulting in elytron code to {{TrustManagerFactory.getDefaultAlgorithm()}} and {{KeyManagerFactory.getDefaultAlgorithm()}}. > It is java portable as for oracle java it returns SunX509 and for Ibm java IbmX509. > This JIRA is in scope of "user experience", minimizing necessary user input configuration. > David: "The trust manager definitely should use the default algorithm when none is given; in this case the algorithm name isn't an "algorithm" per se, it's just an implementation name." -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:44 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2471) Elytron kerberos-security-factory debug attribute type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8012 to WFCORE-2471: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2471 (was: WFLY-8012) Component/s: Security (was: Security) > Elytron kerberos-security-factory debug attribute type > ------------------------------------------------------ > > Key: WFCORE-2471 > URL: https://issues.jboss.org/browse/WFCORE-2471 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: user_experience > > Currently kerberos-security-factory debug attribute is in management model defined as STRING type, but could be BOOLEAN. > {code} > "kerberos-security-factory" => { > "description" => "A security factory for obtaining a GSSCredential for use during authentication.", > "model-description" => {"*" => { > "description" => "A security factory for obtaining a GSSCredential for use during authentication.", > "capabilities" => [{ > "name" => "org.wildfly.security.security-factory.credential", > "dynamic" => true > }], > "attributes" => { > "debug" => { > "type" => STRING, > "description" => "Should the JAAS step of obtaining the credential have debug logging enabled.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > In XSD it is properly configured as boolean > {code:xml} > > > > Should the JAAS step of obtaining the credential have debug logging enabled. > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:46 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2481) Elytron, Can't access application secured with SPNEGO fallbacking to FORM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8285 to WFCORE-2481: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2481 (was: WFLY-8285) Component/s: Security (was: Security) > Elytron, Can't access application secured with SPNEGO fallbacking to FORM > ------------------------------------------------------------------------- > > Key: WFCORE-2481 > URL: https://issues.jboss.org/browse/WFCORE-2481 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > When accessing application configured with SPNEGO + FORM fallback, then user get 404 on first http GET. > {code} > [mchoma at localhost ~]$ curl -v http://localhost.localdomain:8080/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/SimpleSecuredServlet > * Hostname was NOT found in DNS cache > * Trying 127.0.0.1... > * Connected to localhost.localdomain (127.0.0.1) port 8080 (#0) > > GET /be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/SimpleSecuredServlet HTTP/1.1 > > User-Agent: curl/7.37.0 > > Host: localhost.localdomain:8080 > > Accept: */* > > > < HTTP/1.1 404 Not Found > < Expires: 0 > < Cache-Control: no-cache, no-store, must-revalidate > < X-Powered-By: Undertow/1 > < Set-Cookie: JSESSIONID=0O3kk4WJTVuH0XuWriO_d_M6HMCb83Ri7UZmtUU0.localhost; path=/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5 > * Server JBoss-EAP/7 is not blacklisted > < Server: JBoss-EAP/7 > < Pragma: no-cache > < Date: Fri, 03 Mar 2017 09:15:41 GMT > < Connection: keep-alive > < WWW-Authenticate: Negotiate > < Content-Type: text/html;charset=UTF-8 > < Content-Length: 149 > < > * Connection #0 to host localhost.localdomain left intact > Error/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/http:/localhost.localdomain:8080/login.jsp[mchoma at localhost ~]$ > {code} > Changing in web.xml {{SPNEGO,FORM}} to {{SPNEGO}} makes SPNEGO work again. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:46 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2478) Credential store, during creation of CS backed keystore is not created on filesystem. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8266 to WFCORE-2478: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2478 (was: WFLY-8266) Component/s: Security (was: Security) > Credential store, during creation of CS backed keystore is not created on filesystem. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2478 > URL: https://issues.jboss.org/browse/WFCORE-2478 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > Keystore is created after writing secret key into it. So instead of "write alias" operation it is more "write alias and create backed keystore if not exists yet" operation. > How to reproduce: > - create credential store from scratch > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.config.dir) > {"outcome" => "success"} > {code} > - myCredStore.jceks does not exists on FS (I would expect it will be created) > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=myCredStore/alias=myAlias:add(secret-value=secret) > {"outcome" => "success"} > {code} > - myCredStore.jceks exists on FS > Setting high priority as lack of this behaviour can lead to more complex problems in multiprocess scenarios (e.g domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:45 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2474) keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7423 to WFCORE-2474: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2474 (was: WFLY-7423) Component/s: Security (was: Security) > keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute. > ---------------------------------------------------------------------- > > Key: WFCORE-2474 > URL: https://issues.jboss.org/browse/WFCORE-2474 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Priority: Minor > > KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute. > There is "credential-reference" element that is replacement for "password" attribute. > Please remove "password" attribute from keyStoreType. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:47 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2484) CS tool, log exception on error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8199 to WFCORE-2484: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2484 (was: WFLY-8199) Component/s: Security (was: Security) > CS tool, log exception on error > ------------------------------- > > Key: WFCORE-2484 > URL: https://issues.jboss.org/browse/WFCORE-2484 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store, wildfly-elytron-tool > > When I try to create CS with invalid options I get just {{ELY09526: Unable to initialize credential store}}. For example: > * I tried JKS, but JKS is unable to store secret keys > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JKS" --password mycspassword --salt 12345678 --iteration 230 --summary > ELY09526: Unable to initialize credential store[mchoma at localhost bin]$ > {code} > * I tried BKS, but have not BC among providers > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=BKS" --password mycspassword --salt 12345678 --iteration 230 --summary > ELY09526: Unable to initialize credential store > {code} > It would be useful if underlying exception is logged as well. For example subsystem throws this exception and it is obvious what is wrong. > {code} > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09526: Unable to initialize credential store > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:834) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:758) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:163) > at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:119) > at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:117) > ... 5 more > Caused by: java.security.KeyStoreException: BKS not found > at java.security.KeyStore.getInstance(KeyStore.java:851) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:832) > ... 9 more > Caused by: java.security.NoSuchAlgorithmException: BKS KeyStore not available > at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) > at java.security.Security.getImpl(Security.java:695) > at java.security.KeyStore.getInstance(KeyStore.java:848) > ... 10 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:44 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2470) There is missing option to set absolute path for credential store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7972 to WFCORE-2470: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2470 (was: WFLY-7972) Component/s: Security (was: Security) > There is missing option to set absolute path for credential store. > ------------------------------------------------------------------- > > Key: WFCORE-2470 > URL: https://issues.jboss.org/browse/WFCORE-2470 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > There is missing option to set absolute path for credential store. > I expect absolute path defined in URI attribute. Some like this: > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/tmp/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:46 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2480) CS tool, provide way to create empty credential store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8195 to WFCORE-2480: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2480 (was: WFLY-8195) Component/s: Security (was: Security) > CS tool, provide way to create empty credential store > ----------------------------------------------------- > > Key: WFCORE-2480 > URL: https://issues.jboss.org/browse/WFCORE-2480 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: credential-store, wildfly-elytron-tool > > There is no way to create empty credential store. Curently credential store can be created only with adding alias as well. > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary > {code} > I would expect something like > {code} > java -jar wildfly-elytron-tool.jar credential-store --create --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:47 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2485) CS tool, add prompt when --password is missing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8188 to WFCORE-2485: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2485 (was: WFLY-8188) Component/s: Security (was: Security) > CS tool, add prompt when --password is missing > ---------------------------------------------- > > Key: WFCORE-2485 > URL: https://issues.jboss.org/browse/WFCORE-2485 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: credential-store > > Use case: > - User have automation script using cs tool and user don't want to have password stored in file. > - User don't want credential store password to be stored in shell history after execution. > - User don't want credential store password to be listed in {{ps -aux}} output. > There have to be possibility to omit --password attribute. When omitting --password attribute user interaction prompt should follow with possibility to input password. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:48 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2487) Elytron mapped-regex-realm-mapper "name" attribute has wrong description. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7685 to WFCORE-2487: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2487 (was: WFLY-7685) Component/s: Security (was: Security) > Elytron mapped-regex-realm-mapper "name" attribute has wrong description. > ------------------------------------------------------------------------- > > Key: WFCORE-2487 > URL: https://issues.jboss.org/browse/WFCORE-2487 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Dmitrii Tikhomirov > > Elytron mapped-regex-realm-mapper "name" attribute has wrong description. > {code} > https://github.com/wildfly-security/elytron-subsystem/blob/580569d17cb6c3b1e823a2149b156c36d186f0dd/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1925 > {code} > *Actual description* > {code} > The unique name for the RealmMapper, note names used for NameRewriters must be unique > across the whole context. > {code} > *Expected description* > {code} > The unique name for the RealmMapper, note names used for RealmMappers must be unique > across the whole context. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:49 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2490) Multiple CredentialStores with ONE backed credential store file can rewrite values each other. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7623 to WFCORE-2490: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2490 (was: WFLY-7623) Component/s: Security (was: Security) > Multiple CredentialStores with ONE backed credential store file can rewrite values each other. > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-2490 > URL: https://issues.jboss.org/browse/WFCORE-2490 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Priority: Blocker > > Multiple CredentialStores with ONE backed credential store file can rewrite values each other. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true") > /subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron) > {code} > {code} > /subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123") > {code} > check CS file > there is "alias1" entry > {code} > /subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron) > {code} > check CS file > there are "alias1" and "alias2" entries > {code} > /subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron) > {code} > check CS file > there are "alias1" and "alias123" entries". > *NOTE* > It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries. > In my opinion reason for this behaviour is: > We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file. > We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour. > *My suggestion for default behaviour* > When we want to add new alias to CredentialStore we can do this: > # refresh CS from file (and this file lock) > # add new alias to CS > # save CS to file > # unlock file > *But there is posible problem with performance....* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:48 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2486) Legacy ldap realm returns 401 if LDAP is unreachable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8308 to WFCORE-2486: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2486 (was: WFLY-8308) Component/s: Security (was: Security) > Legacy ldap realm returns 401 if LDAP is unreachable > ---------------------------------------------------- > > Key: WFCORE-2486 > URL: https://issues.jboss.org/browse/WFCORE-2486 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > Contradics JBEAP-8125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:50 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:50 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2493) Confusing attribute named http-server-factories in Elytron aggregate-http-server-mechanism-factory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7455 to WFCORE-2493: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2493 (was: WFLY-7455) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Confusing attribute named http-server-factories in Elytron aggregate-http-server-mechanism-factory > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-2493 > URL: https://issues.jboss.org/browse/WFCORE-2493 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Elytron {{aggregate-http-server-mechanism-factory}} includes attribute named {{http-server-factories}} which refers {{org.wildfly.security.http-server-mechanism-factory}} capability. Name of this attribute should be changed from {{http-server-factories}} to {{http-server-mechanism-factories}} because: > * it should be consistent with other Elytron resources which uses name {{http-server-mechanism-factory}} > * it can be confused since {{http-server-factories}} seems as it may also refer some {{org.wildfly.security.http-authentication-factory}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:47 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2483) There is missing CS integration with core management In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8299 to WFCORE-2483: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2483 (was: WFLY-8299) Component/s: Security (was: Security) > There is missing CS integration with core management > ---------------------------------------------------- > > Key: WFCORE-2483 > URL: https://issues.jboss.org/browse/WFCORE-2483 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > Priority is BLOCKER because this issue blocks RFE verification https://issues.jboss.org/browse/EAP7-538 > There must be credential store integration with core management as is mentioned in requirements of RFE. > *management/security-realm* > *management/security-realm/authentication/truststore* keystore-password > *management/security-realm/server-identity/ssl* key-password and keystore-password > *management/security-realm/server-identity/secret* > *management/security-realm/authentication/users* > But *security-realm* is deprecated, these resources have this description: > {code} > The security-realm configuration is deprecated and may be removed or moved in future versions. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:51 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8182 to WFCORE-2497: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2497 (was: WFLY-8182) Component/s: Security (was: Security) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:51 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2496) Functionality in WildFly to encrypt database passwords In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7900 to WFCORE-2496: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2496 (was: WFLY-7900) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 10.1.0.Final) > Functionality in WildFly to encrypt database passwords > ------------------------------------------------------ > > Key: WFCORE-2496 > URL: https://issues.jboss.org/browse/WFCORE-2496 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Carlton Zachary > Assignee: Darran Lofthouse > > Is it possible to add functionality to WildFly to encrypt a data source password when the data source is being created? Currently WildFly/EAP stores the password as plain text in the domain.xml/standalone.xml. > Thanks -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:50 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:50 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2492) CS tool, missing parameters compared to management API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8201 to WFCORE-2492: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2492 (was: WFLY-8201) Component/s: Security (was: Security) > CS tool, missing parameters compared to management API > ------------------------------------------------------ > > Key: WFCORE-2492 > URL: https://issues.jboss.org/browse/WFCORE-2492 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store, wildfly-elytron-tool > > compared to management API I am missing these parameters: > * {{entry-type}} > * -{{providers}} + {{provider-name}}- > ** -user can gain alternative behaviour by editing java.security file- > * {{other-providers}} > ** user can gain alternative behaviour by editing java.security file. But it has to be ensured these providers are injected to implementation throught SPI -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:50 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:50 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2494) Auto-completion does not work for default-realm of Elytron security-domain in CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7585 to WFCORE-2494: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2494 (was: WFLY-7585) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) > Auto-completion does not work for default-realm of Elytron security-domain in CLI > --------------------------------------------------------------------------------- > > Key: WFCORE-2494 > URL: https://issues.jboss.org/browse/WFCORE-2494 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Minor > Labels: user_experience > > Auto-completion does not work for default-realm of Elytron security-domain in CLI. All attributes of security-domain support auto-completion through {{}} button. The only one which does not support it is default-realm. It is probably caused by missing capability-reference. > Example: > {code} > /subsystem=elytron/security-domain=domain:add(default-realm= > {code} > Does not show any security realms. However: > {code} > /subsystem=elytron/security-domain=domain:add(permission-mapper= > {code} > Shows possible permission mappers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:51 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2495) Autocomplete doesn't work properly in credential-reference.alias attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8023 to WFCORE-2495: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2495 (was: WFLY-8023) Component/s: Security (was: Security) > Autocomplete doesn't work properly in credential-reference.alias attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2495 > URL: https://issues.jboss.org/browse/WFCORE-2495 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > > Autocomplete doesn't work properly in credential-reference.alias attribute. > I want to use autocomplete for credential-reference.alias when I the credential-reference.store attribute is filled but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store=cs012, alias= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:49 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2491) Complicated failure-description in Elytron constant-permission-mapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7502 to WFCORE-2491: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2491 (was: WFLY-7502) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta7 (was: 11.0.0.Alpha1) Fix Version/s: 4.0.0.Alpha1 (was: 11.0.0.Alpha1) > Complicated failure-description in Elytron constant-permission-mapper > --------------------------------------------------------------------- > > Key: WFCORE-2491 > URL: https://issues.jboss.org/browse/WFCORE-2491 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > There is complicated failure-description in Elytron constant-permission-mapper. Failure description in CLI should not contain Exception or snippet of stacktrace. Please instead of "Caused by:" parts from example below use some non-java administrator friendly message. > Complicated failure-description: > {code} > /subsystem=elytron/constant-permission-mapper=permission-mapper:add(permissions=[{class-name=WrongClass}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.permission-mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.permission-mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [WrongClass]. > Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"WrongClass\" > Caused by: java.lang.ClassNotFoundException: WrongClass from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules/system/layers/base))]"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.permission-mapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:49 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2489) CS tool, add prompt when --secret is missing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8189 to WFCORE-2489: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2489 (was: WFLY-8189) Component/s: Security (was: Security) > CS tool, add prompt when --secret is missing > -------------------------------------------- > > Key: WFCORE-2489 > URL: https://issues.jboss.org/browse/WFCORE-2489 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: credential-store > > Use case: > - User have automation script using cs tool and user don't want secret value be stored in file. > - User don't want secret value to be stored in shell history after execution. > - User don't want secret value to be listed in {{ps -aux}} output. > There have to be possibility to omit --secret attribute. When omitting --secret attribute user interaction prompt should follow with possibility to input secret value. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 13:16:48 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 7 Mar 2017 13:16:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2488) Elytron keystore type default value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7970 to WFCORE-2488: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2488 (was: WFLY-7970) Component/s: Security (was: Security) > Elytron keystore type default value > ----------------------------------- > > Key: WFCORE-2488 > URL: https://issues.jboss.org/browse/WFCORE-2488 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Make attribute type optional during key-store creation. If not set default value "JKS" can be used. > Basically in this issue is requesting same behaviour as legacy keystore in realms > {code:jsonl|title=ManagementModel} > "keystore-provider" => { > "type" => STRING, > "description" => "The provider for loading the keystore, defaults to JKS.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => "JKS", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > Extracted from WFLY-7125 and tracked as separate issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 17:33:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Tue, 7 Mar 2017 17:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8252) HttpServletRequest.logout() doesn't work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor reassigned WFLY-8252: -------------------------------- Assignee: Pedro Igor (was: Stuart Douglas) > HttpServletRequest.logout() doesn't work with Elytron > ----------------------------------------------------- > > Key: WFLY-8252 > URL: https://issues.jboss.org/browse/WFLY-8252 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: Pedro Igor > Priority: Blocker > > Calling {{HttpServletRequest.logout()}} leaves user logged in if Elytron security is used. > This means security flaw, therefor setting priority to blocker. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 17:35:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 7 Mar 2017 17:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8315) JGroups protocols collect statistics by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-9370 to WFLY-8315: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8315 (was: JBEAP-9370) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR13) > JGroups protocols collect statistics by default > ----------------------------------------------- > > Key: WFLY-8315 > URL: https://issues.jboss.org/browse/WFLY-8315 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > By default, statistics collection should be disabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 17:54:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Tue, 7 Mar 2017 17:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8252) HttpServletRequest.logout() doesn't work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor reassigned WFLY-8252: -------------------------------- Assignee: Stuart Douglas (was: Pedro Igor) > HttpServletRequest.logout() doesn't work with Elytron > ----------------------------------------------------- > > Key: WFLY-8252 > URL: https://issues.jboss.org/browse/WFLY-8252 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Blocker > > Calling {{HttpServletRequest.logout()}} leaves user logged in if Elytron security is used. > This means security flaw, therefor setting priority to blocker. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 18:41:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 7 Mar 2017 18:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2498) org.wildfly.openssl module should be private In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9371 to WFCORE-2498: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2498 (was: JBEAP-9371) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management Modules (was: Domain Management) (was: Modules) (was: Web (Undertow)) Affects Version/s: (was: 7.1.0.DR11) > org.wildfly.openssl module should be private > -------------------------------------------- > > Key: WFCORE-2498 > URL: https://issues.jboss.org/browse/WFCORE-2498 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Modules > Reporter: Stuart Douglas > Assignee: Dmitrii Tikhomirov > Priority: Blocker > > If there is no reason why users have to use this new module directly we should not make it public. Is there any such reason? > It should be fixed in Alpha to avoid changing module visibility in public available releases. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:38:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374376#comment-13374376 ] viet nguyen commented on HAWKULARQE-52: --------------------------------------- Coding completed with several default metrics (see Prometheus endpoint: http://example-promgen.origin.cloud1.hawkular.org/metrics) App deployed with 30 pods. > Create a load generator > ----------------------- > > Key: HAWKULARQE-52 > URL: https://issues.jboss.org/browse/HAWKULARQE-52 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 30pods.png, promgen.png > > > I'm building a load generator app with the following features: > 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram > 2. Runable as an OpenShift pod with required mapconfig for HOSA > 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:38:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-52: ---------------------------------- Attachment: 30pods.png > Create a load generator > ----------------------- > > Key: HAWKULARQE-52 > URL: https://issues.jboss.org/browse/HAWKULARQE-52 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 30pods.png, promgen.png > > > I'm building a load generator app with the following features: > 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram > 2. Runable as an OpenShift pod with required mapconfig for HOSA > 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:38:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-52: ---------------------------------- Attachment: promgen.png > Create a load generator > ----------------------- > > Key: HAWKULARQE-52 > URL: https://issues.jboss.org/browse/HAWKULARQE-52 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 30pods.png, promgen.png > > > I'm building a load generator app with the following features: > 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram > 2. Runable as an OpenShift pod with required mapconfig for HOSA > 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:38:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-52) Create a load generator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen resolved HAWKULARQE-52. ----------------------------------- Resolution: Done > Create a load generator > ----------------------- > > Key: HAWKULARQE-52 > URL: https://issues.jboss.org/browse/HAWKULARQE-52 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 30pods.png, promgen.png > > > I'm building a load generator app with the following features: > 1. Prometheus-style endpoint `/metrics` with basic metric types such as gauge, counter, histogram > 2. Runable as an OpenShift pod with required mapconfig for HOSA > 3. Can scale up as many pods as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:40:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:40:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-58) Research how to add quickapp template to OpenShift cluster In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-58: ------------------------------------- Summary: Research how to add quickapp template to OpenShift cluster Key: HAWKULARQE-58 URL: https://issues.jboss.org/browse/HAWKULARQE-58 Project: Hawkular QE Issue Type: Task Reporter: viet nguyen Assignee: mfoley user -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:42:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-58) Research how to add quickapp template to OpenShift cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-58: ---------------------------------- Parent: HAWKULARQE-24 Issue Type: Sub-task (was: Task) > Research how to add quickapp template to OpenShift cluster > ---------------------------------------------------------- > > Key: HAWKULARQE-58 > URL: https://issues.jboss.org/browse/HAWKULARQE-58 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: mfoley user > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:44:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-58) Research how to add quickapp template to OpenShift cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen resolved HAWKULARQE-58. ----------------------------------- Resolution: Done > Research how to add quickapp template to OpenShift cluster > ---------------------------------------------------------- > > Key: HAWKULARQE-58 > URL: https://issues.jboss.org/browse/HAWKULARQE-58 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:44:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-58) Research how to add quickapp template to OpenShift cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-58: ------------------------------------- Assignee: viet nguyen (was: mfoley user) > Research how to add quickapp template to OpenShift cluster > ---------------------------------------------------------- > > Key: HAWKULARQE-58 > URL: https://issues.jboss.org/browse/HAWKULARQE-58 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:44:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-58) Research how to add quickapp template to OpenShift cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374378#comment-13374378 ] viet nguyen commented on HAWKULARQE-58: --------------------------------------- question: https://github.com/openshift/origin/issues/13209 > Research how to add quickapp template to OpenShift cluster > ---------------------------------------------------------- > > Key: HAWKULARQE-58 > URL: https://issues.jboss.org/browse/HAWKULARQE-58 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: mfoley user > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 19:47:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 7 Mar 2017 19:47:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) Perform and document a small load test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374380#comment-13374380 ] viet nguyen commented on HAWKULARQE-47: --------------------------------------- Building a small Python app to gather some test statistics > Perform and document a small load test run > ------------------------------------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 20:00:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 7 Mar 2017 20:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374381#comment-13374381 ] Stuart Douglas commented on WFLY-8306: -------------------------------------- You are going to need to provide more details, ideally some kind of reproducer. In particular: - How big is the zip, is it larger that the default max-entity-size of 10mb? - Fixed length or chunked? > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > Priority: Blocker > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 20:00:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 7 Mar 2017 20:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas updated WFLY-8306: --------------------------------- Priority: Major (was: Blocker) > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 23:21:00 2017 From: issues at jboss.org (Manjunath S Paramesan (JIRA)) Date: Tue, 7 Mar 2017 23:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1469) Using ExternalSpreadsheetCompiler in osgi throws java.lang.ClassNotFoundException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374391#comment-13374391 ] Manjunath S Paramesan commented on DROOLS-1469: ----------------------------------------------- Hi, I have added a reproducer. The bundle with the compiler https://github.com/manjunath-sp/drools-template-issue-reproducer/tree/master/drools.template.compiler The PAX exam to reproduce the issue https://github.com/manjunath-sp/drools-template-issue-reproducer/tree/master/drools.template.compiler.itest The issue seems to occur when rules are compiled in the init-method of the bundle, whereas when invoked as service the compilation works. Thanks, Manjunath > Using ExternalSpreadsheetCompiler in osgi throws java.lang.ClassNotFoundException > --------------------------------------------------------------------------------- > > Key: DROOLS-1469 > URL: https://issues.jboss.org/browse/DROOLS-1469 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > > Trying to compile a rule template using ExternalSpreadsheetCompiler, the rule compilation works correctly in stand alone eclipse project, but when done inside an OSGI bundle the following exception is throw at runtime: > {code} > java.lang.ClassNotFoundException: Unable to find class 'org.drools.template.parser.DefaultGenerator' > at org.drools.core.base.ClassTypeResolver.resolveType(ClassTypeResolver.java:241) > at org.drools.core.base.ClassTypeResolver.resolveType(ClassTypeResolver.java:130) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.processGlobals(KnowledgeBuilderImpl.java:1640) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.processOtherDeclarations(KnowledgeBuilderImpl.java:1613) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.mergePackage(KnowledgeBuilderImpl.java:1605) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:980) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:365) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:341) > at org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(DefaultTemplateRuleBase.java:133) > at org.drools.template.parser.DefaultTemplateRuleBase.(DefaultTemplateRuleBase.java:56) > at org.drools.template.parser.TemplateDataListener.(TemplateDataListener.java:74) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:99) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:85) > at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.compileRules(DroolsBundleTracker.java:204) > at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.addNewRulesFromContexts(DroolsBundleTracker.java:183) > at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.addingBundle(DroolsBundleTracker.java:119) > at com.mlnms.common.fmwk.drools.impl.DroolsBundleTracker.addingBundle(DroolsBundleTracker.java:67) > at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 01:15:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 8 Mar 2017 01:15:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2499) Elytron, using wrong provider-http-server-mechanism-factory does not generates any log messages In-Reply-To: References: Message-ID: Martin Choma created WFCORE-2499: ------------------------------------ Summary: Elytron, using wrong provider-http-server-mechanism-factory does not generates any log messages Key: WFCORE-2499 URL: https://issues.jboss.org/browse/WFCORE-2499 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse When I secure management interface with wrongly configured http-authentication-factory and try to authenticate I get no error except of warning during boot {code} 11:41:16,140 WARN [org.jboss.as.remoting] (MSC service thread 1-2) ****** All authentication is ANONYMOUS for org.jboss.as.remoting.RemotingHttpUpgradeService {code} But user is not able to know what is going wrong. When I do similar for deployment there is at least error during boot: {code} 14:30:59,608 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 63) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./secured-webapp: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./secured-webapp: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory. at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory. at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:241) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) ... 6 more Caused by: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory. at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:463) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425) at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415) at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) ... 8 more 14:30:59,613 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "secured-webapp.war")]) - failure description: { "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./secured-webapp" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./secured-webapp: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory. Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory. Caused by: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory."}, "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./secured-webapp"] } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 01:30:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 8 Mar 2017 01:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2500) Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state In-Reply-To: References: Message-ID: Martin Choma created WFCORE-2500: ------------------------------------ Summary: Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state Key: WFCORE-2500 URL: https://issues.jboss.org/browse/WFCORE-2500 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Changing attribute changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state even though header allow-resource-service-restart=true is used {code} [standalone at localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true} { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} Header should work as attribute is declared as {{"restart-required" => "resource-services"}} {code} "http-server-mechanism-factory" => { "type" => STRING, "description" => "The HttpServerAuthenticationMechanismFactory to associate with this resource", "expressions-allowed" => false, "required" => true, "nillable" => false, "capability-reference" => "org.wildfly.security.http-server-mechanism-factory", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } {code} And according to documentation [1]: resource-services ? The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.) [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 01:56:00 2017 From: issues at jboss.org (Einat Peretz (JIRA)) Date: Wed, 8 Mar 2017 01:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374405#comment-13374405 ] Einat Peretz commented on WFLY-8306: ------------------------------------ Not big zip. There is no problem for zip sizes less than 891 bytes, more than 891 bytes and only 891 bytes are received. This is the http coming from the client: Host: localhost:8888 User-Agent: gSOAP/2.7 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 5674 Connection: keep-alive Authorization: Basic dmFsb3I6dmFsb3J2cGw= SOAPAction: "urn:getPartsForPartsStatus" vNPIfalseAQAAAAEAAADASy85PjsXelbT/P7G++N0HLxem2xeQ9zso7w0/TurAd0DK9ahSEDLdtXwrQxknZVVD6FZPnsfduh/gJiHZNs/243f13AHbCTgEBb33LFPsQ==AQAAAAEAAADASy85PjsXelbT/P7G++N0HLxem2xeQ9zso7w0/TurAbn+tE6Sx83y7Kh7PeibcAFrBt88j3UVYeJiF/vYsbGoAQAAAAEAAADASy85PjsXelbT/P7G++N0HLxem2xeQ9zso7w0/TurAW2h2ghhjuSweQOktNKBPg5s6yo0BWcO91WQWCycJF1yAQAAAAEAAADASy85PjsXelbT/P7G++N0HLxem2xeQ9zso7w0/TurAQfCb7GlzlBZ/7S3+GS1ybDdYtauFt3rZdxlMhdOCrXSvNPIvNPItruefalsetrueH4sIAAAAAAAAAO3dbW/ixhoG4L9irVSp1alhXjy2kSiSMebNGKhxWMg3TuJW6CQQYbpS/31nTHY3TttztjCPdD7c0ioiJBj20mgy88w9nu7D8bn1afd0PLU+vTy1Ho/Pu/2hVZWnT/uHstIPqmp/PLSWu1/LvKxejoeq7HVPr4+Sw3l/3peV8/C0q6qfPvzltX4775+q1svudNZXOZ1X5935t8rdnU673z/0ut/+kl73+eXQi3Puu5wx6Q7Tbts8031+OD6WvWg11d/XD7tPx4fdWX/sXnf/2JPdtv769bm1ebdu++vvPJbVw2n/8vWHzno5c1aaoNS/9/anb19VvX4ofW1+eYfD7ll/jOUyX6yTQbddf1tf/M2T9bfd9ucX/1tf7z/l4/B4ysvn47m8e3ncncveL7unquy2/+an3fY/QbsBePY/gZ1T+Ut5Kg8P5U8fWq22/vftb/fF8kP7s+ZNl7tcwlzs/1BVSCEC5vka1muyLsfbeJEtQXstbRbnTCb3y6FptA3afDHO4Hp9RxB/ZD6TjnZNh2kSNWzXk9U42kL3Wl0ju40589KoEE3aaL2B69Wt1sDWrl4exQ3XNMmSArLXyo7yjIdhHvBLq2V80NDN7vKoiMB79QhByNAJQt/hyvc6GCJYtw39QNtyBlvLw68xDy89borRl11WFemx1wCsFocHM876pq0uwvl83hwfrKJsdTcfAfcWXN0RsLgPXLK6DP+WwhdU/7kqql1WJ7dK9wSynty244wztQly84Ria0x2bU92NSsmuzST3XHdijHZJSuHC5TDycrhHDMH2zMHmWJwS7fWwFPGsNRANMZlGOPaHuNGnPEhFnBIlh29NHD+1BcM8mi2yCcxfG+dMwjMGWzLcsH82AvUvbeO4iBkDLpWdevqYpB1lmi3tue6Sum5boK5LlkpQcWmlKAHC+CliiVIidZLWggT4CXglTwbKl6PGzTvDLyWeUWS+2xqBg6JYOC1zduJFyPzh00xd1lA12aFwWNC1ItmYV+wZr+LMvnNkTAhgpDzThgIyFoP26lLkFFI2JKFRGFLtSbJsSZJRdsBLQmtF2AlnYjWD9EhUIQUHJNSMMs8SCmQpD8YXClcc7gSuPrvl8vgeovra1pJIK1Egiv50NRrF0ONmwDXMq6ITLX25zVwbeNOs1QK1a+r4ZnbLNcWW3c7mMP26ob75n4JOUKMVLp6oABdsvytHt0C1zZubFZy0nwT5GHfRMgbuttolCyAe33L5b5rss332BVpF9XszUFi3OZ6br0rUkqBW/7YdQ2ZUriVknVXE7jdDoTw4Wq3d60T+KYfQAKfQtYLZCoha1lWd7J1H4s2SxSwTUy7RcCWincsBPLLhLz1uBa81nkF71/S9/U9F5Fftsxbx8N5rEe5iIcTxr4kAjQktFIim0RF2xFotSS0HcGYD1mCHM14itgXSTxJ97NwpXDtCNykynLsy8zEEPsiSiaZcvhiimSSdVw9NKjvEVpPxQp31cwm1TfBBu1VtMlr6MvAIvRFFEvS4657pGYoZPXQC4EvOt1OKqBLFqdLEacjCScJwQSySQSlWoVSLRGtwL5yQlq0WiJaAVoiWo+JELQEtH6Ae3jQlWzF+zsmoWR7oysPteuUY2O53Xoi9zcqN6eV+mmBaqL1ygEXAeoydLoKpQM6XRGmAXSJdAX2P1Piol+gwxUpbIlsvZxhocE2bh6breXD3GVBfduJ5pwXW8tvxDUHukwvuKC12im8btTjUzXCdjK75QSHtZgvPzqXacR3Dg+D/N22hlkxQTHMrrKf8g6U7Sp/OZjosrk/DLE7x6Lu5+MFvDTA8QIUCxFOwDzH55KJmdN28ljgoAEiY1kbA5kQ2XeEYFiuJEvdYLmSKL/gSeQXaGglUjd0tB3QEqVuOh2cQUJDG3CFVktEq3ByDlFWzAtAaz/T5NTnu4ydobNx9BSYO+xH/hH5JgLi75c/1MoSyvbXKWac1csU2E9NgMt9FsZsxMdGuGCMzRHTIwiSIY1DqBsiBEkY08vFdA5cGlyJJBmlLk996JLpitSDLpluyjrQpdL1Ojl0yXSVSCV0qXT9ToiENJWu8NB0yXD1aBe9LhWuCT8Clwg34KkCLhWuwoGH1nHf7ErxAmycsEn75UCImDOFAyFs8/bv10q5sVgHDdb5ZumuYrBev4ymG61psDgw3T5uMdveccbC5t+wYrEaT/roCm4eIXAmxNBsaS8wRrDaarMt183WHa1YCFmbsvfZn/6AwfTGzqDesJrmG5UH/b4QCmNae7jDqWs2Wrv83b3J42w5L9w4RxDvatpJvAqVVNHI1TOFYUN3MsAu65tcA48xaWQFZC3mGqMN97mX3EX/as5so80EQcZbWH1fBFkBVpuss5/HUsRznrPs/TYzlGJuo50PE8mXBWc85sn7WyuA9hbaZTxlUw2bxTM+ah60M5/E40m8wIkw15cQIz3kQvXQqmghlAdSmz1AshrItVyJu6gArNVKN2d9Ibx0gQ0j9gexy3uzZWQlBH9X7MZOkVsqsaPL+sH3BfN+wCKC1TrBeLYUSqj+IMnNJIFxlGUJeOP7JJe5BK9d3tVETxJE7hbcTSRkLcpuYm893JjlLy6GwxHnSjTHCpvJbDLfAPh64I4SYbiZuUG8GomQgfe/kbVPZfVyPFRlcjjvz/uy+rvXV+Xp0/6hrPSDqtL/WX2VX8v89cW9PwDS0DAhTeIAAA== > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 02:00:00 2017 From: issues at jboss.org (Einat Peretz (JIRA)) Date: Wed, 8 Mar 2017 02:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374408#comment-13374408 ] Einat Peretz commented on WFLY-8306: ------------------------------------ We use Axis2 messageReceivers with EJB, so the EJB method call is: public DataHandler getPartsForPartsStatus(RequestDescriptor source, DataHandler attachment) > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 03:54:05 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 03:54:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8316) Mapping roles in legacy security domain is ignored when this domain is used as Elytron realm In-Reply-To: References: Message-ID: Ondrej Lukas created WFLY-8316: ---------------------------------- Summary: Mapping roles in legacy security domain is ignored when this domain is used as Elytron realm Key: WFLY-8316 URL: https://issues.jboss.org/browse/WFLY-8316 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when legacy security domain is used as Elytron realm then roles assigned in mapping are unavailable in Elytron security realm. e.g. when UsersRoles login module, which assigns role JBossAdmin to user admin is used and then role User is assigned for user admin in SimpleRoles mapping module through: {code} {code} then only role JBossAdmin is available for Elytron. Following appears in server log: {code} Authorizing against the following attributes: [Roles, CallerPrincipal] => [JBossAdmin, admin] {code} In case when this legacy security domain is used directly as PicketBox security domain, then both roles, JBossAdmin and User, are assigned to user admin. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 03:55:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 03:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8316) Mapping roles in legacy security domain is ignored when this domain is used as Elytron realm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFLY-8316: ------------------------------- Attachment: print-roles.war > Mapping roles in legacy security domain is ignored when this domain is used as Elytron realm > -------------------------------------------------------------------------------------------- > > Key: WFLY-8316 > URL: https://issues.jboss.org/browse/WFLY-8316 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: print-roles.war > > > In case when legacy security domain is used as Elytron realm then roles assigned in mapping are unavailable in Elytron security realm. > e.g. when UsersRoles login module, which assigns role JBossAdmin to user admin is used and then role User is assigned for user admin in SimpleRoles mapping module through: > {code} > > > > > > {code} > then only role JBossAdmin is available for Elytron. Following appears in server log: > {code} > Authorizing against the following attributes: [Roles, CallerPrincipal] => [JBossAdmin, admin] > {code} > In case when this legacy security domain is used directly as PicketBox security domain, then both roles, JBossAdmin and User, are assigned to user admin. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 03:56:01 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 8 Mar 2017 03:56:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2501) When is thrown exception in custom-principal-decoder implementation I cannot see any exception in log. In-Reply-To: References: Message-ID: Hynek ?v?bek created WFCORE-2501: ------------------------------------ Summary: When is thrown exception in custom-principal-decoder implementation I cannot see any exception in log. Key: WFCORE-2501 URL: https://issues.jboss.org/browse/WFCORE-2501 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse When is thrown exception in custom-principal-decoder implementation I cannot see any exception in log. Log level is set to TRACE. You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:02:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 8 Mar 2017 04:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2413) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFCORE-2413: --------------------------------- Priority: Blocker (was: Critical) > Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2413 > URL: https://issues.jboss.org/browse/WFCORE-2413 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError. > I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError. > You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:09:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Mar 2017 04:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services for standalone xmls under examples directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated WFLY-8314: ---------------------------------- Summary: WFLY starts with errors and missing services for standalone xmls under examples directory (was: WFLY starts with errors and missing services in standalone-xts and standalone-rts profile) > WFLY starts with errors and missing services for standalone xmls under examples directory > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:11:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Mar 2017 04:11:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services for standalone xmls under examples directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374472#comment-13374472 ] Ondra Chaloupka commented on WFLY-8314: --------------------------------------- the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-jts.xml standalone-picketlink.xml standalone-rts.xml standalone-xts.xml {code} > WFLY starts with errors and missing services for standalone xmls under examples directory > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:19:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Mar 2017 04:19:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services for standalone xmls under examples directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374472#comment-13374472 ] Ondra Chaloupka edited comment on WFLY-8314 at 3/8/17 4:18 AM: --------------------------------------------------------------- the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-jts.xml standalone-rts.xml standalone-xts.xml {code} was (Author: ochaloup): the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-jts.xml standalone-picketlink.xml standalone-rts.xml standalone-xts.xml {code} > WFLY starts with errors and missing services for standalone xmls under examples directory > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:26:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Mar 2017 04:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services for standalone xmls under examples directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374478#comment-13374478 ] Ondra Chaloupka commented on WFLY-8314: --------------------------------------- [~dlofthouse][~swd847]: would you be so kind and check my addition of elytron to configs under examples directory? would that be ok from your point of view? Thanks! https://github.com/wildfly/wildfly/pull/9760 > WFLY starts with errors and missing services for standalone xmls under examples directory > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:32:04 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Mar 2017 04:32:04 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services for standalone xmls under examples directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374472#comment-13374472 ] Ondra Chaloupka edited comment on WFLY-8314 at 3/8/17 4:31 AM: --------------------------------------------------------------- the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-picketlink.xml standalone-jts.xml standalone-rts.xml standalone-xts.xml {code} was (Author: ochaloup): the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-jts.xml standalone-rts.xml standalone-xts.xml {code} > WFLY starts with errors and missing services for standalone xmls under examples directory > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:36:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Mar 2017 04:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8314) WFLY starts with errors and missing services for standalone xmls under examples directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374472#comment-13374472 ] Ondra Chaloupka edited comment on WFLY-8314 at 3/8/17 4:35 AM: --------------------------------------------------------------- the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-picketlink.xml standalone-jts.xml standalone-rts.xml standalone-xts.xml {code} Based on WFLY-8300 there are more errors at startup of {{standalone-picketlink.xml}} but this should solve only the startup error for http-invoker which depends on elytron subsystem. was (Author: ochaloup): the trouble does not influence only the {{standalone-xts.xml}} but all these configs under examples directory {code} standalone-activemq-colocated.xml standalone-genericjms.xml standalone-picketlink.xml standalone-jts.xml standalone-rts.xml standalone-xts.xml {code} > WFLY starts with errors and missing services for standalone xmls under examples directory > ----------------------------------------------------------------------------------------- > > Key: WFLY-8314 > URL: https://issues.jboss.org/browse/WFLY-8314 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > When starting EAP 7.1.0.DR13 with {{./jboss-eap-7.1/bin/standalone.sh --server-config=../../docs/examples/configs/standalone-xts.xml}}, the following errors are logged: > {code}09:27:48,895 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("setting" => "http-invoker") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.application-http-authentication]"] > } > 09:27:48,912 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service org.wildfly.security.http-authentication-factory.application-http-authentication (missing) dependents: [service jboss.undertow.server.default-server.default-host.http-invoker] > 09:27:49,003 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0212: Resuming server > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 09:27:49,005 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 09:27:49,005 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started (with errors) in 3975ms - Started 435 of 677 services (1 services failed or missing dependencies, 440 services are lazy, passive or on-demand) > {code} > This seems to be the result of adding a {{http-invoker}} into Undertow subsystem that references and Elytron {{http-authentication-factory}}. This configuration file does not have Elytron subsystem added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 04:49:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 8 Mar 2017 04:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7307) Some XTS tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reassigned WFLY-7307: ------------------------------- Assignee: (was: Jan Tymel) > Some XTS tests fail with security manager > ----------------------------------------- > > Key: WFLY-7307 > URL: https://issues.jboss.org/browse/WFLY-7307 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorApplicationException* > *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCannotComplete* > *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorClientCancel* > *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCompletionFailToComplete* > *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple* > *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSingle* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BACoordinatorCompletionTestCase -Dsecurity.manager}} > {code} > 13:49:00,854 ERROR [stderr] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/wsba-coordinatorcompletition-test.war/WEB-INF/lib/arquillian-core.jar )" of "ModuleClassLoader for Module "deployment.wsba-coordinatorcompletition-test.war:main" from Service Module Loader") > 13:49:00,856 ERROR [stderr] (default task-1) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > 13:49:00,857 ERROR [stderr] (default task-1) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > 13:49:00,859 ERROR [stderr] (default task-1) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128) > 13:49:00,872 ERROR [stderr] (default task-1) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220) > 13:49:00,873 ERROR [stderr] (default task-1) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181) > 13:49:00,874 ERROR [stderr] (default task-1) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286) > 13:49:00,874 ERROR [stderr] (default task-1) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57) > 13:49:00,886 ERROR [stderr] (default task-1) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44) > 13:49:00,890 ERROR [stderr] (default task-1) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169) > 13:49:00,891 ERROR [stderr] (default task-1) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135) > 13:49:00,894 ERROR [stderr] (default task-1) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98) > 13:49:00,895 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > 13:49:00,898 ERROR [stderr] (default task-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > 13:49:00,899 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > 13:49:00,900 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > 13:49:00,901 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > 13:49:00,908 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > 13:49:00,909 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:49:00,910 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > 13:49:00,911 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > 13:49:00,911 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:49:00,916 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > 13:49:00,917 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > 13:49:00,918 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > 13:49:00,920 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > 13:49:00,923 ERROR [stderr] (default task-1) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > 13:49:00,924 ERROR [stderr] (default task-1) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > 13:49:00,925 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:49:00,927 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > 13:49:00,928 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:49:00,929 ERROR [stderr] (default task-1) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:49:00,930 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > 13:49:00,931 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > 13:49:00,933 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > 13:49:00,934 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > 13:49:00,935 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > 13:49:00,935 ERROR [stderr] (default task-1) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > 13:49:00,939 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > 13:49:00,940 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:49:00,941 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:49:00,942 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:49:00,943 ERROR [stderr] (default task-1) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:49:00,944 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > 13:49:00,944 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > 13:49:00,945 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > 13:49:00,946 ERROR [stderr] (default task-1) at java.security.AccessController.doPrivileged(Native Method) > 13:49:00,947 ERROR [stderr] (default task-1) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > 13:49:00,948 ERROR [stderr] (default task-1) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > 13:49:00,952 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 13:49:00,953 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:49:00,955 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:49:00,956 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745) > {code} > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationException* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationExceptionCommit* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATClientRollback* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATRollbackOnly* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSimple* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSingleSimple* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollback* > *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollbackPrePrepare* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=ATTestCase -Dsecurity.manager}} > {code} > 13:52:13,655 ERROR [stderr] (default task-2) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/wsat-test.war/WEB-INF/lib/arquillian-core.jar )" of "ModuleClassLoader for Module "deployment.wsat-test.war:main" from Service Module Loader") > 13:52:13,656 ERROR [stderr] (default task-2) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > 13:52:13,657 ERROR [stderr] (default task-2) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > 13:52:13,658 ERROR [stderr] (default task-2) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128) > 13:52:13,658 ERROR [stderr] (default task-2) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220) > 13:52:13,659 ERROR [stderr] (default task-2) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181) > 13:52:13,660 ERROR [stderr] (default task-2) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286) > 13:52:13,660 ERROR [stderr] (default task-2) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57) > 13:52:13,661 ERROR [stderr] (default task-2) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44) > 13:52:13,662 ERROR [stderr] (default task-2) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169) > 13:52:13,662 ERROR [stderr] (default task-2) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135) > 13:52:13,663 ERROR [stderr] (default task-2) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98) > 13:52:13,664 ERROR [stderr] (default task-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > 13:52:13,664 ERROR [stderr] (default task-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > 13:52:13,665 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > 13:52:13,666 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > 13:52:13,666 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > 13:52:13,667 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > 13:52:13,668 ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:52:13,668 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > 13:52:13,669 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > 13:52:13,669 ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:52:13,670 ERROR [stderr] (default task-2) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > 13:52:13,671 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > 13:52:13,671 ERROR [stderr] (default task-2) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > 13:52:13,672 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > 13:52:13,673 ERROR [stderr] (default task-2) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > 13:52:13,673 ERROR [stderr] (default task-2) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > 13:52:13,674 ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:52:13,677 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > 13:52:13,678 ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:52:13,679 ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:52:13,680 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > 13:52:13,681 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > 13:52:13,682 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > 13:52:13,683 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > 13:52:13,684 ERROR [stderr] (default task-2) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > 13:52:13,685 ERROR [stderr] (default task-2) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > 13:52:13,685 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > 13:52:13,686 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:52:13,687 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:52:13,689 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:52:13,690 ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:52:13,691 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > 13:52:13,692 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > 13:52:13,693 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > 13:52:13,694 ERROR [stderr] (default task-2) at java.security.AccessController.doPrivileged(Native Method) > 13:52:13,695 ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > 13:52:13,696 ERROR [stderr] (default task-2) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > 13:52:13,696 ERROR [stderr] (default task-2) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 13:52:13,698 ERROR [stderr] (default task-2) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:52:13,699 ERROR [stderr] (default task-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:52:13,699 ERROR [stderr] (default task-2) at java.lang.Thread.run(Thread.java:745) > {code} > *org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction* > *org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=TransactionalTestCase -Dsecurity.manager}} > {code} > 13:53:42,849 ERROR [stderr] (default task-6) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/transactional-test.war/WEB-INF/lib/arquillian-core.jar )" of "ModuleClassLoader for Module "deployment.transactional-test.war:main" from Service Module Loader") > 13:53:42,854 ERROR [stderr] (default task-6) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > 13:53:42,855 ERROR [stderr] (default task-6) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > 13:53:42,855 ERROR [stderr] (default task-6) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128) > 13:53:42,856 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220) > 13:53:42,858 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181) > 13:53:42,859 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286) > 13:53:42,859 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57) > 13:53:42,860 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44) > 13:53:42,861 ERROR [stderr] (default task-6) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169) > 13:53:42,861 ERROR [stderr] (default task-6) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135) > 13:53:42,862 ERROR [stderr] (default task-6) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98) > 13:53:42,863 ERROR [stderr] (default task-6) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > 13:53:42,863 ERROR [stderr] (default task-6) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > 13:53:42,864 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > 13:53:42,865 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > 13:53:42,865 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > 13:53:42,866 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > 13:53:42,866 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:53:42,867 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > 13:53:42,867 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > 13:53:42,868 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:53:42,868 ERROR [stderr] (default task-6) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > 13:53:42,869 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > 13:53:42,869 ERROR [stderr] (default task-6) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > 13:53:42,870 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > 13:53:42,870 ERROR [stderr] (default task-6) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > 13:53:42,871 ERROR [stderr] (default task-6) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > 13:53:42,871 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:53:42,872 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > 13:53:42,872 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:53:42,873 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:53:42,873 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > 13:53:42,874 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > 13:53:42,874 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > 13:53:42,875 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > 13:53:42,875 ERROR [stderr] (default task-6) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > 13:53:42,875 ERROR [stderr] (default task-6) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > 13:53:42,876 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > 13:53:42,878 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:53:42,880 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:53:42,881 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:53:42,882 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:53:42,882 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > 13:53:42,883 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > 13:53:42,883 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > 13:53:42,884 ERROR [stderr] (default task-6) at java.security.AccessController.doPrivileged(Native Method) > 13:53:42,885 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > 13:53:42,885 ERROR [stderr] (default task-6) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > 13:53:42,886 ERROR [stderr] (default task-6) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 13:53:42,886 ERROR [stderr] (default task-6) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:53:42,887 ERROR [stderr] (default task-6) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:53:42,887 ERROR [stderr] (default task-6) at java.lang.Thread.run(Thread.java:745) > {code} > *org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testActiveTransaction* > *org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testNoTransaction* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=CompensatableTestCase -Dsecurity.manager}} > {code} > 13:55:03,742 ERROR [stderr] (default task-6) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/compensatable-test.war/WEB-INF/lib/arquillian-core.jar )" of "ModuleClassLoader for Module "deployment.compensatable-test.war:main" from Service Module Loader") > 13:55:03,743 ERROR [stderr] (default task-6) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > 13:55:03,744 ERROR [stderr] (default task-6) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > 13:55:03,745 ERROR [stderr] (default task-6) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128) > 13:55:03,745 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220) > 13:55:03,746 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181) > 13:55:03,747 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286) > 13:55:03,747 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57) > 13:55:03,748 ERROR [stderr] (default task-6) at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44) > 13:55:03,749 ERROR [stderr] (default task-6) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169) > 13:55:03,749 ERROR [stderr] (default task-6) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135) > 13:55:03,750 ERROR [stderr] (default task-6) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98) > 13:55:03,750 ERROR [stderr] (default task-6) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > 13:55:03,751 ERROR [stderr] (default task-6) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > 13:55:03,752 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > 13:55:03,752 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > 13:55:03,753 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > 13:55:03,753 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > 13:55:03,757 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:55:03,758 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > 13:55:03,758 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > 13:55:03,759 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:55:03,759 ERROR [stderr] (default task-6) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > 13:55:03,760 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > 13:55:03,760 ERROR [stderr] (default task-6) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > 13:55:03,761 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > 13:55:03,762 ERROR [stderr] (default task-6) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > 13:55:03,762 ERROR [stderr] (default task-6) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > 13:55:03,763 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:55:03,763 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > 13:55:03,764 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:55:03,765 ERROR [stderr] (default task-6) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > 13:55:03,766 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > 13:55:03,766 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > 13:55:03,767 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > 13:55:03,769 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > 13:55:03,774 ERROR [stderr] (default task-6) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > 13:55:03,775 ERROR [stderr] (default task-6) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > 13:55:03,776 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > 13:55:03,776 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:55:03,777 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:55:03,777 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:55:03,778 ERROR [stderr] (default task-6) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > 13:55:03,779 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > 13:55:03,779 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > 13:55:03,780 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > 13:55:03,781 ERROR [stderr] (default task-6) at java.security.AccessController.doPrivileged(Native Method) > 13:55:03,782 ERROR [stderr] (default task-6) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > 13:55:03,783 ERROR [stderr] (default task-6) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > 13:55:03,783 ERROR [stderr] (default task-6) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 13:55:03,784 ERROR [stderr] (default task-6) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:55:03,785 ERROR [stderr] (default task-6) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:55:03,786 ERROR [stderr] (default task-6) at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 05:02:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 8 Mar 2017 05:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects In-Reply-To: References: Message-ID: Geoffrey De Smet created DROOLS-1470: ---------------------------------------- Summary: Match.getObjects() should also include accumulate's objects Key: DROOLS-1470 URL: https://issues.jboss.org/browse/DROOLS-1470 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.0.0.Beta6 Reporter: Geoffrey De Smet Assignee: Mario Fusco More info coming once I 've created an isolated reproducer for this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:13:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 8 Mar 2017 06:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2502) Legacy ldap realm, entry for non existing user are cached In-Reply-To: References: Message-ID: Martin Choma created WFCORE-2502: ------------------------------------ Summary: Legacy ldap realm, entry for non existing user are cached Key: WFCORE-2502 URL: https://issues.jboss.org/browse/WFCORE-2502 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse In case when cache is used for legacy LDAP security realm and any access to secured resource occures, then entry is added into cache even if user has not been authenticated correctly. This can cause that valid entries are evicted due to max-cache-size. This reduce benefit of LDAP cache and impacts performance. Same behavior can be seen in 7.0.0.GA. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:16:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 06:16:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2503) Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2503: ------------------------------------ Summary: Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm Key: WFCORE-2503 URL: https://issues.jboss.org/browse/WFCORE-2503 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Attachments: print-roles.war In case when legacy security domain is used as Elytron security realm and is added as authorization realm to aggregate-realm then no roles are assigned to authenticated user. I tried to use following legacy security domain: {code} {code} Roles should be assigned from mapping. Since it seems that there is no documentation related to this topic I am not sure whether roles should be assigned also from rolesProperties of UsersRoles login module - it needs to be clarified by developers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:16:02 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 06:16:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2503) Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2503: --------------------------------- Attachment: print-roles.war > Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2503 > URL: https://issues.jboss.org/browse/WFCORE-2503 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: print-roles.war > > > In case when legacy security domain is used as Elytron security realm and is added as authorization realm to aggregate-realm then no roles are assigned to authenticated user. > I tried to use following legacy security domain: > {code} > > > > > > > > > > > > > > {code} > Roles should be assigned from mapping. Since it seems that there is no documentation related to this topic I am not sure whether roles should be assigned also from rolesProperties of UsersRoles login module - it needs to be clarified by developers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:20:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 8 Mar 2017 06:20:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1470: ------------------------------------- Description: Given this DRL: {code} global java.util.List list rule R when $t : CarType(id == \"roadster\") accumulate( $c : Car(type == $t); $total : count($c) )\ then list.addAll(kcontext.getMatch().getObjects()); end {code} and then inserting the roadster type and 3 cars of that type: {code} CarType roadsterType = new CarType("roadster"); ksession.insert(roadsterType); Car bmwZ4 = new Car("BMW Z4", roadsterType); ksession.insert(bmwZ4); Car lotusElise = new Car("Lotus Elise", roadsterType); ksession.insert(lotusElise); Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); ksession.insert(mazdaMx5); {code} then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. was:More info coming once I 've created an isolated reproducer for this. > Match.getObjects() should also include accumulate's objects > ----------------------------------------------------------- > > Key: DROOLS-1470 > URL: https://issues.jboss.org/browse/DROOLS-1470 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Given this DRL: > {code} > global java.util.List list > rule R when > $t : CarType(id == \"roadster\") > accumulate( > $c : Car(type == $t); > $total : count($c) > )\ > then > list.addAll(kcontext.getMatch().getObjects()); > end > {code} > and then inserting the roadster type and 3 cars of that type: > {code} > CarType roadsterType = new CarType("roadster"); > ksession.insert(roadsterType); > Car bmwZ4 = new Car("BMW Z4", roadsterType); > ksession.insert(bmwZ4); > Car lotusElise = new Car("Lotus Elise", roadsterType); > ksession.insert(lotusElise); > Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); > ksession.insert(mazdaMx5); > {code} > then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. > Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:20:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 8 Mar 2017 06:20:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374550#comment-13374550 ] Geoffrey De Smet commented on DROOLS-1470: ------------------------------------------ Pr with reproducing unit test submitted. > Match.getObjects() should also include accumulate's objects > ----------------------------------------------------------- > > Key: DROOLS-1470 > URL: https://issues.jboss.org/browse/DROOLS-1470 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Given this DRL: > {code} > global java.util.List list > rule R when > $t : CarType(id == \"roadster\") > accumulate( > $c : Car(type == $t); > $total : count($c) > )\ > then > list.addAll(kcontext.getMatch().getObjects()); > end > {code} > and then inserting the roadster type and 3 cars of that type: > {code} > CarType roadsterType = new CarType("roadster"); > ksession.insert(roadsterType); > Car bmwZ4 = new Car("BMW Z4", roadsterType); > ksession.insert(bmwZ4); > Car lotusElise = new Car("Lotus Elise", roadsterType); > ksession.insert(lotusElise); > Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); > ksession.insert(mazdaMx5); > {code} > then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. > Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:22:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 8 Mar 2017 06:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374550#comment-13374550 ] Geoffrey De Smet edited comment on DROOLS-1470 at 3/8/17 6:21 AM: ------------------------------------------------------------------ Pr with reproducing unit test submitted. https://github.com/droolsjbpm/drools/pull/1131 was (Author: ge0ffrey): Pr with reproducing unit test submitted. > Match.getObjects() should also include accumulate's objects > ----------------------------------------------------------- > > Key: DROOLS-1470 > URL: https://issues.jboss.org/browse/DROOLS-1470 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Given this DRL: > {code} > global java.util.List list > rule R when > $t : CarType(id == \"roadster\") > accumulate( > $c : Car(type == $t); > $total : count($c) > )\ > then > list.addAll(kcontext.getMatch().getObjects()); > end > {code} > and then inserting the roadster type and 3 cars of that type: > {code} > CarType roadsterType = new CarType("roadster"); > ksession.insert(roadsterType); > Car bmwZ4 = new Car("BMW Z4", roadsterType); > ksession.insert(bmwZ4); > Car lotusElise = new Car("Lotus Elise", roadsterType); > ksession.insert(lotusElise); > Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); > ksession.insert(mazdaMx5); > {code} > then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. > Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:23:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 8 Mar 2017 06:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374550#comment-13374550 ] Geoffrey De Smet edited comment on DROOLS-1470 at 3/8/17 6:22 AM: ------------------------------------------------------------------ Pr with reproducing unit test submitted. https://github.com/droolsjbpm/drools/pull/1131/files#diff-29e145e93ea28f58485219d51e5887e1R130 was (Author: ge0ffrey): Pr with reproducing unit test submitted. https://github.com/droolsjbpm/drools/pull/1131 > Match.getObjects() should also include accumulate's objects > ----------------------------------------------------------- > > Key: DROOLS-1470 > URL: https://issues.jboss.org/browse/DROOLS-1470 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Given this DRL: > {code} > global java.util.List list > rule R when > $t : CarType(id == \"roadster\") > accumulate( > $c : Car(type == $t); > $total : count($c) > )\ > then > list.addAll(kcontext.getMatch().getObjects()); > end > {code} > and then inserting the roadster type and 3 cars of that type: > {code} > CarType roadsterType = new CarType("roadster"); > ksession.insert(roadsterType); > Car bmwZ4 = new Car("BMW Z4", roadsterType); > ksession.insert(bmwZ4); > Car lotusElise = new Car("Lotus Elise", roadsterType); > ksession.insert(lotusElise); > Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); > ksession.insert(mazdaMx5); > {code} > then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. > Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:26:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 06:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-986) Method equals for MatchRule throws java.lang.IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374551#comment-13374551 ] Ondrej Lukas commented on ELY-986: ---------------------------------- Please uncomment following line [1] when this issue will be fixed. [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb6d2652442236a062310af01f6f14f0aea8c3d3/src/test/java/org/wildfly/security/auth/client/AuthenticationContextTest.java#L342 > Method equals for MatchRule throws java.lang.IllegalStateException > ------------------------------------------------------------------ > > Key: ELY-986 > URL: https://issues.jboss.org/browse/ELY-986 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In case when method {{equals(MatchRule other)}} is called on {{org.wildfly.security.auth.client.MatchRule}} then it finishes with java.lang.IllegalStateException with following stack trace, for calling {{MatchRule.ALL.equals(MatchRule.ALL);}}: > {code} > java.lang.IllegalStateException > at org.wildfly.security.auth.client.MatchRule$1.getMatchUser(MatchRule.java:102) > at org.wildfly.security.auth.client.MatchRule.getMatchUser(MatchRule.java:500) > at org.wildfly.security.auth.client.MatchNoUserRule.halfEqual(MatchNoUserRule.java:46) > at org.wildfly.security.auth.client.MatchRule.equals(MatchRule.java:157) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:27:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 06:27:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-986) Method equals for MatchRule throws java.lang.IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374551#comment-13374551 ] Ondrej Lukas edited comment on ELY-986 at 3/8/17 6:26 AM: ---------------------------------------------------------- Please uncomment following line [1] when this issue will be fixed (it can be done as part of PR which will fix this issue). [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb6d2652442236a062310af01f6f14f0aea8c3d3/src/test/java/org/wildfly/security/auth/client/AuthenticationContextTest.java#L342 was (Author: olukas): Please uncomment following line [1] when this issue will be fixed. [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb6d2652442236a062310af01f6f14f0aea8c3d3/src/test/java/org/wildfly/security/auth/client/AuthenticationContextTest.java#L342 > Method equals for MatchRule throws java.lang.IllegalStateException > ------------------------------------------------------------------ > > Key: ELY-986 > URL: https://issues.jboss.org/browse/ELY-986 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In case when method {{equals(MatchRule other)}} is called on {{org.wildfly.security.auth.client.MatchRule}} then it finishes with java.lang.IllegalStateException with following stack trace, for calling {{MatchRule.ALL.equals(MatchRule.ALL);}}: > {code} > java.lang.IllegalStateException > at org.wildfly.security.auth.client.MatchRule$1.getMatchUser(MatchRule.java:102) > at org.wildfly.security.auth.client.MatchRule.getMatchUser(MatchRule.java:500) > at org.wildfly.security.auth.client.MatchNoUserRule.halfEqual(MatchNoUserRule.java:46) > at org.wildfly.security.auth.client.MatchRule.equals(MatchRule.java:157) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:29:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 06:29:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374553#comment-13374553 ] Ondrej Lukas commented on ELY-988: ---------------------------------- As part of fix please remove related ignores in [1]. It can be done as part of PR which will fix this issue. [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/test/java/org/wildfly/security/auth/client/AuthenticationContextTest.java > Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly > --------------------------------------------------------------------------------------- > > Key: ELY-988 > URL: https://issues.jboss.org/browse/ELY-988 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. > In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: > * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created > * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created > Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:50:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 8 Mar 2017 06:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374568#comment-13374568 ] ehsavoie Hugonnet commented on WFCORE-2360: ------------------------------------------- Removing the server will trigger a model synchronization on the slave which happens before the RUNTIME phase during which the server status is checked, so we fail before the verify-server-status operation. > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain at localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain at localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:55:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 8 Mar 2017 06:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2504) Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7996 to WFCORE-2504: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2504 (was: WFLY-7996) Component/s: Security (was: Security) Fix Version/s: 3.0.0.Beta8 (was: 11.0.0.Alpha1) > Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2504 > URL: https://issues.jboss.org/browse/WFCORE-2504 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The default Elytron configuration in profiles doesn't configure {{JBOSS-LOCAL-USER}} SASL mechanism for ApplicationRealm. If a client (e.g JMS/naming) uses local authentication in legacy security, it will not work after switching to Elytron based security. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 06:59:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 8 Mar 2017 06:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2504) Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2504: ------------------------------- Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/402, https://github.com/wildfly-security-incubator/wildfly-core/pull/52 (was: https://github.com/wildfly-security/elytron-subsystem/pull/402, https://github.com/wildfly-security/elytron-subsystem/pull/442) > Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2504 > URL: https://issues.jboss.org/browse/WFCORE-2504 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The default Elytron configuration in profiles doesn't configure {{JBOSS-LOCAL-USER}} SASL mechanism for ApplicationRealm. If a client (e.g JMS/naming) uses local authentication in legacy security, it will not work after switching to Elytron based security. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 07:07:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 8 Mar 2017 07:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2505) Key store exported from legacy security domain does not work Elytron filtering-key-store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek moved JBEAP-9398 to WFCORE-2505: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2505 (was: JBEAP-9398) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta6 (was: 7.1.0.DR13) > Key store exported from legacy security domain does not work Elytron filtering-key-store > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2505 > URL: https://issues.jboss.org/browse/WFCORE-2505 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta6 > Reporter: Ondrej Kotek > Priority: Critical > > It is not possible to use a key store exported from legacy security domain (i.e. {{elytron-key-store}}) in Elytron {{filtering-key-store}}. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService > Caused by: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"] > }, > "rolled-back" => true > } > {noformat} > The exported key store is announced as {{org.wildfly.security.key-store}} capability. Hence it is expected to work wherever the capability is requested. > The same applies to {{elytron-trust-store}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 07:08:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 8 Mar 2017 07:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2505) Key store exported from legacy security domain does not work Elytron filtering-key-store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek updated WFCORE-2505: --------------------------------- Steps to Reproduce: # {{/subsystem=security/security-domain=cert-roles-domain:add}} # {noformat}/subsystem=security/security-domain=cert-roles-domain/jsse=classic:add(truststore={password=secret, url="/path/to/server.truststore.jks"}, keystore={password=secret, url="/path/to/server.keystore.jks"}, client-auth=true){noformat} # {{/subsystem=security/elytron-key-store=eks:add(legacy-jsse-config=cert-roles-domain)}} # {{/subsystem=elytron/filtering-key-store=fks:add(alias-filter=ALL,key-store=eks)}} was: # {{/subsystem=security/security-domain=cert-roles-domain:add}} # {{/subsystem=security/security-domain=cert-roles-domain/jsse=classic:add(truststore={password=secret, url="/path/to/server.truststore.jks"}, keystore={password=secret, url="/path/to/server.keystore.jks"}, client-auth=true)}} # {{/subsystem=security/elytron-key-store=eks:add(legacy-jsse-config=cert-roles-domain)}} # {{/subsystem=elytron/filtering-key-store=fks:add(alias-filter=ALL,key-store=eks)}} > Key store exported from legacy security domain does not work Elytron filtering-key-store > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2505 > URL: https://issues.jboss.org/browse/WFCORE-2505 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta6 > Reporter: Ondrej Kotek > Priority: Critical > > It is not possible to use a key store exported from legacy security domain (i.e. {{elytron-key-store}}) in Elytron {{filtering-key-store}}. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService > Caused by: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"] > }, > "rolled-back" => true > } > {noformat} > The exported key store is announced as {{org.wildfly.security.key-store}} capability. Hence it is expected to work wherever the capability is requested. > The same applies to {{elytron-trust-store}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 07:09:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 8 Mar 2017 07:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8317) Stack element in JGroups subsystem allows arbitrary attribute to be defined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-9399 to WFLY-8317: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8317 (was: JBEAP-9399) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR13) > Stack element in JGroups subsystem allows arbitrary attribute to be defined > --------------------------------------------------------------------------- > > Key: WFLY-8317 > URL: https://issues.jboss.org/browse/WFLY-8317 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > When adding foo="bar" attribute to element in JGroups subsystem and running the EAP, the XML validation passes. > There should Validation error thrown instead. > {code:xml|title=JGroups subsystem configuration} > > > > > > > > > > > > > > > > > > > > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 07:27:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 07:27:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2503) Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2503: --------------------------------- Steps to Reproduce: 1) create property files /tmp/users.properties and /tmp/roles.properties /tmp/users.properties: {code} admin=admin {code} /roles.properties: {code} admin=JBossAdmin {code} 2) Through add-user.sh add user admin with some password and role Admin for ApplicationRealm 3) add legacy configuration to application server {code} ... {code} 4) setup Elytron part: {code} /subsystem=elytron/simple-role-decoder=roles-decoder:add(attribute=Roles) /subsystem=elytron/aggregate-realm=pbauthz:add(authentication-realm=ApplicationRealm,authorization-realm=exportedDomain) /subsystem=elytron/security-domain=elytronDomain:add(default-realm=pbauthz,permission-mapper=default-permission-mapper,realms=[{realm=pbauthz,role-decoder=roles-decoder}]) /subsystem=elytron/http-authentication-factory=elytron-http-auth:add(http-server-mechanism-factory=global,security-domain=elytronDomain,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name="Exported Realm"}]}]) /subsystem=undertow/application-security-domain=print-roles:add(http-authentication-factory=elytron-http-auth) {code} 5) Deploy application for printing roles (see attachments) 6) Access http://127.0.0.1:8080/print-roles/protected/printRoles?role=User&role=JBossAdmin&role=Admin and login with admin/admin - no roles are assigned (HTTP status cod 403 is returned) was: 1) create property files /tmp/users.properties and /tmp/roles.properties /tmp/users.properties: {code} admin=admin {code} /roles.properties: {code} admin=JBossAdmin {code} 2) Through add-user.sh add user admin with some password and role Admin 3) add legacy configuration to application server {code} ... {code} 4) setup Elytron part: {code} /subsystem=elytron/simple-role-decoder=roles-decoder:add(attribute=Roles) /subsystem=elytron/aggregate-realm=pbauthz:add(authentication-realm=ApplicationRealm,authorization-realm=exportedDomain) /subsystem=elytron/security-domain=elytronDomain:add(default-realm=pbauthz,permission-mapper=default-permission-mapper,realms=[{realm=pbauthz,role-decoder=roles-decoder}]) /subsystem=elytron/http-authentication-factory=elytron-http-auth:add(http-server-mechanism-factory=global,security-domain=elytronDomain,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name="Exported Realm"}]}]) /subsystem=undertow/application-security-domain=print-roles:add(http-authentication-factory=elytron-http-auth) {code} 5) Deploy application for printing roles (see attachments) 6) Access http://127.0.0.1:8080/print-roles/protected/printRoles?role=User&role=JBossAdmin&role=Admin and login with admin/admin - no roles are assigned (HTTP status cod 403 is returned) > Legacy security domain used as Elytron security realm does not work in authorization part of aggregate-realm > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2503 > URL: https://issues.jboss.org/browse/WFCORE-2503 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: print-roles.war > > > In case when legacy security domain is used as Elytron security realm and is added as authorization realm to aggregate-realm then no roles are assigned to authenticated user. > I tried to use following legacy security domain: > {code} > > > > > > > > > > > > > > {code} > Roles should be assigned from mapping. Since it seems that there is no documentation related to this topic I am not sure whether roles should be assigned also from rolesProperties of UsersRoles login module - it needs to be clarified by developers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 07:35:00 2017 From: issues at jboss.org (Sande Gilda (JIRA)) Date: Wed, 8 Mar 2017 07:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8318) [7.1] Configuration Guide - typo in Configuring Handlers section In-Reply-To: References: Message-ID: Sande Gilda created WFLY-8318: --------------------------------- Summary: [7.1] Configuration Guide - typo in Configuring Handlers section Key: WFLY-8318 URL: https://issues.jboss.org/browse/WFLY-8318 Project: WildFly Issue Type: Enhancement Components: Documentation Reporter: Sande Gilda The sentence reads: "Reverse-proxy handlers allow JBoss EAP to server as a high performance reverse-proxy. " It should read: "Reverse-proxy handlers allow JBoss EAP to serve as a high performance reverse-proxy. " -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 07:53:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 8 Mar 2017 07:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2506) Roles are not assigned if access=identity uses Elytron security domain based on legacy security domain In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2506: ------------------------------------ Summary: Roles are not assigned if access=identity uses Elytron security domain based on legacy security domain Key: WFCORE-2506 URL: https://issues.jboss.org/browse/WFCORE-2506 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when Elytron security domain, which uses legacy security domain (provided through elytron-integration in legacy security subsystem), is used for identity inflow in access=identity, and authentication is provided by security domain which uses some Elytron security realm, then no roles/groups from legacy security domain are assigned to the secured identity. See reproducer for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 08:59:01 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 8 Mar 2017 08:59:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2507) Key manager exported from legacy security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek moved JBEAP-9411 to WFCORE-2507: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2507 (was: JBEAP-9411) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta6 (was: 7.1.0.DR13) > Key manager exported from legacy security domain does not work Elytron server-ssl-context > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2507 > URL: https://issues.jboss.org/browse/WFCORE-2507 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta6 > Reporter: Ondrej Kotek > Priority: Critical > > It is not possible to use a key manager exported from legacy security domain (i.e. {{elytron-key-manager}}) in Elytron {{server-ssl-context}}. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] > }, > "rolled-back" => true > } > {noformat} > The exported key manager is announced as {{org.wildfly.security.key-managers}} capability. Hence it is expected to work wherever the capability is requested. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 09:07:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 8 Mar 2017 09:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-59) Hawkular Agent over HTTPS In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-59: ---------------------------------------- Summary: Hawkular Agent over HTTPS Key: HAWKULARQE-59 URL: https://issues.jboss.org/browse/HAWKULARQE-59 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: mfoley user For EAP7 and EAP6.4 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 09:10:00 2017 From: issues at jboss.org (Balavignesh sethupathi (JIRA)) Date: Wed, 8 Mar 2017 09:10:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8319) Undertow doesn't process HTTPS request sometimes In-Reply-To: References: Message-ID: Balavignesh sethupathi created WFLY-8319: -------------------------------------------- Summary: Undertow doesn't process HTTPS request sometimes Key: WFLY-8319 URL: https://issues.jboss.org/browse/WFLY-8319 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 9.0.2.Final, 8.2.1.Final Environment: Redhat Linux 7.2 Reporter: Balavignesh sethupathi Assignee: Stuart Douglas Attachments: testSuite.tar.gz We are seeing this issue in undertow 1.4.8 where it fails to process a POST(HTTPS) request sent from the SOAPUI client sometimes. We have the related info updated in the below JBoss thread: https://developer.jboss.org/thread/273775 In short, seems like the default task thread which handled the previous HTTPS SOAP request drains the next request that is waiting to get serviced. This seems to be race condition which happens intermittently. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 09:20:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 09:20:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374668#comment-13374668 ] Brian Stansberry commented on WFCORE-2360: ------------------------------------------ Why does the model synchronization fail? > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain at localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain at localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 09:35:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 8 Mar 2017 09:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8320) Fixes related to the clustering testsuite failures In-Reply-To: References: Message-ID: Farah Juma created WFLY-8320: -------------------------------- Summary: Fixes related to the clustering testsuite failures Key: WFLY-8320 URL: https://issues.jboss.org/browse/WFLY-8320 Project: WildFly Issue Type: Bug Components: EJB Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:02:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 8 Mar 2017 10:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1424) Variance and standard deviation function in Drools out of the box In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet reassigned DROOLS-1424: ---------------------------------------- Assignee: Geoffrey De Smet (was: Mario Fusco) > Variance and standard deviation function in Drools out of the box > ----------------------------------------------------------------- > > Key: DROOLS-1424 > URL: https://issues.jboss.org/browse/DROOLS-1424 > Project: Drools > Issue Type: Feature Request > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > After a bunch of research I've found the way to do this efficiently: > https://en.wikipedia.org/wiki/Algorithms_for_calculating_variance#Online_algorithm > Simply use Welford's algorithm. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:05:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 8 Mar 2017 10:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-995) Elytron Audit Logging does not log principal if simple file format is used In-Reply-To: References: Message-ID: Jan Tymel created ELY-995: ----------------------------- Summary: Elytron Audit Logging does not log principal if simple file format is used Key: ELY-995 URL: https://issues.jboss.org/browse/ELY-995 Project: WildFly Elytron Issue Type: Bug Reporter: Jan Tymel Assignee: Darran Lofthouse Priority: Critical _SIMPLE_ format of Elytron Audit Logging does not contain the information about the principal when the authentication is not successful. _JSON_ format contains such piece of information. Compare _JSON_ format {noformat} 3/8/17 3:53 PM,WARNING,{"event":"SecurityAuthenticationFailedEvent","event-time":"3/8/17 3:53 PM","security-identity":{"name":"anonymous","creation-time":"3/8/17 3:53 PM"},"success":false,"principal":"user"} {noformat} to _SIMPLE_ format {noformat} 3/8/17 3:54 PM,WARNING,event=SecurityAuthenticationFailedEvent,event-time=3/8/17 3:54 PM,security-identity=[name=anonymous,creation-time=3/8/17 3:54 PM],success=false} {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:06:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 8 Mar 2017 10:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-995) Elytron Audit Logging does not log principal if simple file format is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated ELY-995: -------------------------- Steps to Reproduce: * Follow steps _Configure Elytron (default profile)_ in [blog post|http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html] in order to change default configuration to Elytron * Start server and deploy attached war (containing servlet secured with BASIC HTTP auth) * Access http://127.0.0.1:8080/protected/printRoles in a browser * Fill in username and password (authentication will be unsuccessful no matter what is provided) * Change format to simple: {{/subsystem=elytron/file-audit-log=local-audit:write-attribute(name=format,value=SIMPLE)}} * Fill in username and password once more * Check _JBOSS_HOME/standalone/log/audit.log_ was: * Follow steps _Configure Elytron (default profile)_ in [blog post|http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html] in order to change default configuration to Elytron * Start server and deploy attached war (containing servlet secured with BASIC HTTP auth) * Access http://127.0.0.1:8080/protected/printRoles in a browser * Fill in username and password (authentication will be unsuccessful no matter what is provided) * Change format to simple: {{/subsystem=elytron/file-audit-log=local-audit:write-attribute(name=format,value=SIMPLE)}} * Fill in username and password once more * Check that _JBOSS_HOME/standalone/log/audit.log_ > Elytron Audit Logging does not log principal if simple file format is used > -------------------------------------------------------------------------- > > Key: ELY-995 > URL: https://issues.jboss.org/browse/ELY-995 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Priority: Critical > Attachments: deployment.war > > > _SIMPLE_ format of Elytron Audit Logging does not contain the information about the principal when the authentication is not successful. _JSON_ format contains such piece of information. > Compare _JSON_ format > {noformat} > 3/8/17 3:53 PM,WARNING,{"event":"SecurityAuthenticationFailedEvent","event-time":"3/8/17 3:53 PM","security-identity":{"name":"anonymous","creation-time":"3/8/17 3:53 PM"},"success":false,"principal":"user"} > {noformat} > to _SIMPLE_ format > {noformat} > 3/8/17 3:54 PM,WARNING,event=SecurityAuthenticationFailedEvent,event-time=3/8/17 3:54 PM,security-identity=[name=anonymous,creation-time=3/8/17 3:54 PM],success=false} > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:06:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 8 Mar 2017 10:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-995) Elytron Audit Logging does not log principal if simple file format is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reassigned ELY-995: ----------------------------- Assignee: (was: Darran Lofthouse) > Elytron Audit Logging does not log principal if simple file format is used > -------------------------------------------------------------------------- > > Key: ELY-995 > URL: https://issues.jboss.org/browse/ELY-995 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Critical > Attachments: deployment.war > > > _SIMPLE_ format of Elytron Audit Logging does not contain the information about the principal when the authentication is not successful. _JSON_ format contains such piece of information. > Compare _JSON_ format > {noformat} > 3/8/17 3:53 PM,WARNING,{"event":"SecurityAuthenticationFailedEvent","event-time":"3/8/17 3:53 PM","security-identity":{"name":"anonymous","creation-time":"3/8/17 3:53 PM"},"success":false,"principal":"user"} > {noformat} > to _SIMPLE_ format > {noformat} > 3/8/17 3:54 PM,WARNING,event=SecurityAuthenticationFailedEvent,event-time=3/8/17 3:54 PM,security-identity=[name=anonymous,creation-time=3/8/17 3:54 PM],success=false} > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:06:01 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 8 Mar 2017 10:06:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-995) Elytron Audit Logging does not log principal if simple file format is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated ELY-995: -------------------------- Attachment: deployment.war > Elytron Audit Logging does not log principal if simple file format is used > -------------------------------------------------------------------------- > > Key: ELY-995 > URL: https://issues.jboss.org/browse/ELY-995 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Critical > Attachments: deployment.war > > > _SIMPLE_ format of Elytron Audit Logging does not contain the information about the principal when the authentication is not successful. _JSON_ format contains such piece of information. > Compare _JSON_ format > {noformat} > 3/8/17 3:53 PM,WARNING,{"event":"SecurityAuthenticationFailedEvent","event-time":"3/8/17 3:53 PM","security-identity":{"name":"anonymous","creation-time":"3/8/17 3:53 PM"},"success":false,"principal":"user"} > {noformat} > to _SIMPLE_ format > {noformat} > 3/8/17 3:54 PM,WARNING,event=SecurityAuthenticationFailedEvent,event-time=3/8/17 3:54 PM,security-identity=[name=anonymous,creation-time=3/8/17 3:54 PM],success=false} > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:17:01 2017 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 8 Mar 2017 10:17:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8321) IllegalArgumentException in autocomplete of driver-name of datasource add command with embedded server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov moved JBEAP-9417 to WFLY-8321: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8321 (was: JBEAP-9417) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR13) > IllegalArgumentException in autocomplete of driver-name of datasource add command with embedded server > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-8321 > URL: https://issues.jboss.org/browse/WFLY-8321 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 11.0.0.Alpha1 > Reporter: Michal Petrov > Assignee: Michal Petrov > Priority: Minor > > IllegalArgumentException in autocomplete of driver-name of datasource add command with embedded server > {noformat} > Exception in thread "Aesh Process Loop 1006094903" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asList(ModelValue.java:143) > at org.jboss.dmr.ModelNode.asList(ModelNode.java:1566) > at org.jboss.as.cli.handlers.jca.JDBCDriverNameProvider.getAllCandidates(JDBCDriverNameProvider.java:71) > at org.jboss.as.cli.impl.DefaultCompleter.complete(DefaultCompleter.java:64) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:276) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:89) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:429) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:166) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:778) > at org.jboss.aesh.console.Console.execute(Console.java:738) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:647) > 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) > {noformat} > see. Steps to Reproduce -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:34:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 8 Mar 2017 10:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-956) Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374754#comment-13374754 ] Ilia Vassilev commented on ELY-956: ----------------------------------- [~mchoma] ConcurrentHashMap is synchronized, but not locked for exclusive access. We need this code because the list may change. Can we close this issue? > Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory > ------------------------------------------------------------------------------------------------------------- > > Key: ELY-956 > URL: https://issues.jboss.org/browse/ELY-956 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static-analysis scan found a synchronization on java.util.concurrent.ConcurrentHashMap object in: > * {{ElytronPolicyConfigurationFactory.getPolicyConfiguration}} > * {{ElytronPolicyConfigurationFactory.inService}} > If policyConfiguration synchronization is concern, it should be enough to synchronize on policyConfiguration object. > > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123208&mergedDefectId=1377483 > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123209&mergedDefectId=1377485 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 10:37:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 8 Mar 2017 10:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2462) CS tool, format Missing required option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374760#comment-13374760 ] Ilia Vassilev commented on WFCORE-2462: --------------------------------------- [~mchoma] Since we will not change the code, can we close the issue? > CS tool, format Missing required option > --------------------------------------- > > Key: WFCORE-2462 > URL: https://issues.jboss.org/browse/WFCORE-2462 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma at localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 11:43:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 8 Mar 2017 11:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2462) CS tool, format Missing required option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374827#comment-13374827 ] Martin Choma commented on WFCORE-2462: -------------------------------------- Yes > CS tool, format Missing required option > --------------------------------------- > > Key: WFCORE-2462 > URL: https://issues.jboss.org/browse/WFCORE-2462 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma at localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 12:38:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=) Date: Wed, 8 Mar 2017 12:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1427) Get rid of kie-eap-integration modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr ?irok? closed DROOLS-1427. ------------------------------- Resolution: Rejected > Get rid of kie-eap-integration modules > -------------------------------------- > > Key: DROOLS-1427 > URL: https://issues.jboss.org/browse/DROOLS-1427 > Project: Drools > Issue Type: Task > Components: build > Reporter: Petr ?irok? > Assignee: Petr ?irok? > > The {{kie-eap-integration}} should not be needed anymore as KIE should no longer be par of the integration pack (https://github.com/jboss-integration/fuse-bxms-integ). And the only reason to keep the {{kie-eap-integration}} around was the integration pack. > [~tirelli] could you please confirm this? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 12:40:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=) Date: Wed, 8 Mar 2017 12:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-760) Code style formatters are not actual In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374872#comment-13374872 ] Petr ?irok? commented on DROOLS-760: ------------------------------------ There were some changes related to formatting done by [~kgaevski]. I believe the formatters are now up-to-date. [~kgaevski] can you please confirm that? > Code style formatters are not actual > ------------------------------------ > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zim?nyi > Assignee: Petr ?irok? > Priority: Minor > Labels: reported-by-qe > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 12:42:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 12:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6409) Update default domain configuration to use remote+http In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-6409: ----------------------------------- Fix Version/s: 12.0.0.Alpha1 (was: 11.0.0.Alpha1) > Update default domain configuration to use remote+http > ------------------------------------------------------ > > Key: WFLY-6409 > URL: https://issues.jboss.org/browse/WFLY-6409 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 12.0.0.Alpha1 > > > Our default domain configuration still use the native remote protocol on port 9999 for DC-HC communication. Update those files so that we use http-remoting on port 9990. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 13:18:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 8 Mar 2017 13:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet updated WFCORE-2360: -------------------------------------- Affects Version/s: 3.0.0.Beta7 > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta7 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain at localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain at localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 13:19:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 8 Mar 2017 13:19:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374893#comment-13374893 ] ehsavoie Hugonnet commented on WFCORE-2360: ------------------------------------------- because of the verification step on the removal of the server-group associated with the to be removed server This is a regression coming from https://issues.jboss.org/browse/WFCORE-2203 > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta7 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain at localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain at localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 13:32:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 13:32:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8322) EJB3 subsystem should not depend on legacy security subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9424 to WFLY-8322: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8322 (was: JBEAP-9424) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Security (was: EJB) (was: Security) Affects Version/s: (was: 7.1.0.DR11) > EJB3 subsystem should not depend on legacy security subsystem > ------------------------------------------------------------- > > Key: WFLY-8322 > URL: https://issues.jboss.org/browse/WFLY-8322 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Reporter: Jan Martiska > Assignee: Brian Stansberry > Priority: Critical > > After removing the legacy {{security}} subsystem and booting the server, you see > {noformat} > 12:22:54,842 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.security.simple-security-manager"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.utilities is missing [jboss.security.simple-security-manager]"] > } > {noformat} > Which means that EJB3 subsystem requires functionality of the legacy security subsystem. It should be possible to completely get rid of the legacy subsystem and work with just Elytron. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 13:40:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 13:40:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8322) EJB3 subsystem should not depend on legacy security subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-8322: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9763 > EJB3 subsystem should not depend on legacy security subsystem > ------------------------------------------------------------- > > Key: WFLY-8322 > URL: https://issues.jboss.org/browse/WFLY-8322 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Reporter: Jan Martiska > Assignee: Brian Stansberry > Priority: Critical > > After removing the legacy {{security}} subsystem and booting the server, you see > {noformat} > 12:22:54,842 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.security.simple-security-manager"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.utilities is missing [jboss.security.simple-security-manager]"] > } > {noformat} > Which means that EJB3 subsystem requires functionality of the legacy security subsystem. It should be possible to completely get rid of the legacy subsystem and work with just Elytron. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 14:48:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 8 Mar 2017 14:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2462) CS tool, format Missing required option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev closed WFCORE-2462. --------------------------------- Resolution: Won't Fix > CS tool, format Missing required option > --------------------------------------- > > Key: WFCORE-2462 > URL: https://issues.jboss.org/browse/WFCORE-2462 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma at localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 15:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 15:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8323) The datasources and resource-adapters subsystems introduce hard requirements for the legacy security subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9428 to WFLY-8323: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8323 (was: JBEAP-9428) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) > The datasources and resource-adapters subsystems introduce hard requirements for the legacy security subsystem > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8323 > URL: https://issues.jboss.org/browse/WFLY-8323 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Brian Stansberry > Assignee: Stefano Maestri > Priority: Critical > > There are code paths in the connector module that result in dependencies on services provided by the legacy security subsystem being added to ds and r-a services even though the ds or r-a config doesn't require the depended on services. This will force users to retain the legacy subsystem in their config even though it is otherwise unnecessary. > The services are org.jboss.as.security.service.SubjectFactoryService and org.jboss.as.security.service.SimpleSecurityManagerService. > Related to this, the configuration xml includes some 'elytron-enabled' attributes that appear to be redundant, since 'authentication-context' attributes indicate a need for elytron. I believe resolving the main subject of this JIRA may help clarify whether those attributes are adding value, since a fix will involve analysis of what scenarios indicate a requirement for the legacy security services and what do not. If all those cases can be identified without resorting to the user declaring 'elytron-enabled' that's a good sign that 'elytron-enabled' is not adding value. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 16:21:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 8 Mar 2017 16:21:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5688) mod_cluster subsystem remains silent if connector set to undefined connector In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-5688: --------------------------------- Issue Type: Bug (was: Feature Request) > mod_cluster subsystem remains silent if connector set to undefined connector > ---------------------------------------------------------------------------- > > Key: WFLY-5688 > URL: https://issues.jboss.org/browse/WFLY-5688 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.CR4 > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > Labels: ux > > If one sets mod_cluster subsystem {{connector="http"}} there is nothing in the log about any mod_cluster subsystem being initialized, no warning, nothing. It appears to be dead silent even with log level DEBUG. > When switched back to {{connector="ajp"}}, there are the well known comforting messages: > {noformat} > INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final > INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364 > {noformat} > Weird. Any obvious misconfiguration or explanation? The config is the default standalone-ha.xml otherwise. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 16:56:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 16:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374963#comment-13374963 ] Brian Stansberry commented on WFCORE-1958: ------------------------------------------ I'm reverting PR #2218 as the VaultPasswordsInCLITestCase is failing intermittently. > Clean up testsuite Elytron registration > --------------------------------------- > > Key: WFCORE-1958 > URL: https://issues.jboss.org/browse/WFCORE-1958 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them.. > Also re-enable the following test case: - > * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 17:14:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 17:14:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8323) The datasources and resource-adapters subsystems introduce hard requirements for the legacy security subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFLY-8323: -------------------------------------- Assignee: Brian Stansberry (was: Stefano Maestri) > The datasources and resource-adapters subsystems introduce hard requirements for the legacy security subsystem > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8323 > URL: https://issues.jboss.org/browse/WFLY-8323 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > > There are code paths in the connector module that result in dependencies on services provided by the legacy security subsystem being added to ds and r-a services even though the ds or r-a config doesn't require the depended on services. This will force users to retain the legacy subsystem in their config even though it is otherwise unnecessary. > The services are org.jboss.as.security.service.SubjectFactoryService and org.jboss.as.security.service.SimpleSecurityManagerService. > Related to this, the configuration xml includes some 'elytron-enabled' attributes that appear to be redundant, since 'authentication-context' attributes indicate a need for elytron. I believe resolving the main subject of this JIRA may help clarify whether those attributes are adding value, since a fix will involve analysis of what scenarios indicate a requirement for the legacy security services and what do not. If all those cases can be identified without resorting to the user declaring 'elytron-enabled' that's a good sign that 'elytron-enabled' is not adding value. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 17:26:00 2017 From: issues at jboss.org (Manjunath S Paramesan (JIRA)) Date: Wed, 8 Mar 2017 17:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: Manjunath S Paramesan created DROOLS-1471: --------------------------------------------- Summary: Unable to marshall a kieSession running in stream mode. Key: DROOLS-1471 URL: https://issues.jboss.org/browse/DROOLS-1471 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Final Reporter: Manjunath S Paramesan Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 17:28:00 2017 From: issues at jboss.org (Manjunath S Paramesan (JIRA)) Date: Wed, 8 Mar 2017 17:28:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjunath S Paramesan updated DROOLS-1471: ------------------------------------------ Description: Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:206) at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) Caused by: java.lang.NullPointerException at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 18:05:00 2017 From: issues at jboss.org (Kirill Gaevskii (JIRA)) Date: Wed, 8 Mar 2017 18:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-760) Code style formatters are not actual In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13374974#comment-13374974 ] Kirill Gaevskii commented on DROOLS-760: ---------------------------------------- Hi [~psiroky], we decided to use actual formatter in Stunner, I saw some tries in other repositories like Uberfire, but mine goal was Stunner only, so I can't guarantee another repositories use it. > Code style formatters are not actual > ------------------------------------ > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zim?nyi > Assignee: Petr ?irok? > Priority: Minor > Labels: reported-by-qe > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 18:56:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Wed, 8 Mar 2017 18:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chao Wang updated WFLY-6607: ---------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9518 > Broadcast/Discovery group is possible to create with just a name > ---------------------------------------------------------------- > > Key: WFLY-6607 > URL: https://issues.jboss.org/browse/WFLY-6607 > Project: WildFly > Issue Type: Bug > Components: JMS, Web Console > Affects Versions: 10.0.0.Final > Reporter: Chen Maoqian > Assignee: Chen Maoqian > > When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default > user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one) > At this moment it's possible to create broadcast group with just a name which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 20:59:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 20:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2337) Removal of overlay in a server group fails inside a composite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2337: ------------------------------------- Steps to Reproduce: In domain mode, deploy some content. Then run the following composite: {code} { ????"operation" => "composite", ????"address" => [], ????"steps" => [ ????????{ ????????????"address" => [ ????????????????("server-group" => "main-server-group"), ????????????????("deployment-overlay" => "ov1"), ????????????????("deployment" => "toto.war") ????????????], ????????????"operation" => "remove", ????????????"redeploy-affected" => true ????????}, ????????{ ????????????"address" => [ ????????????????("server-group" => "main-server-group"), ????????????????("deployment-overlay" => "ov1") ????????????], ????????????"operation" => "remove" ????????}, ????????{ ????????????"address" => [ ????????????????("server-group" => "other-server-group"), ????????????????("deployment-overlay" => "ov1"), ????????????????("deployment" => "toto.war") ????????????], ????????????"operation" => "remove", ????????????"redeploy-affected" => true ????????}, ????????{ ????????????"address" => [ ????????????????("server-group" => "other-server-group"), ????????????????("deployment-overlay" => "ov1") ????????????], ????????????"operation" => "remove" ????????} ????] } {code} was: In domain mode, deploy some content. Then run the following composite: { ????"operation" => "composite", ????"address" => [], ????"steps" => [ ????????{ ????????????"address" => [ ????????????????("server-group" => "main-server-group"), ????????????????("deployment-overlay" => "ov1"), ????????????????("deployment" => "toto.war") ????????????], ????????????"operation" => "remove", ????????????"redeploy-affected" => true ????????}, ????????{ ????????????"address" => [ ????????????????("server-group" => "main-server-group"), ????????????????("deployment-overlay" => "ov1") ????????????], ????????????"operation" => "remove" ????????}, ????????{ ????????????"address" => [ ????????????????("server-group" => "other-server-group"), ????????????????("deployment-overlay" => "ov1"), ????????????????("deployment" => "toto.war") ????????????], ????????????"operation" => "remove", ????????????"redeploy-affected" => true ????????}, ????????{ ????????????"address" => [ ????????????????("server-group" => "other-server-group"), ????????????????("deployment-overlay" => "ov1") ????????????], ????????????"operation" => "remove" ????????} ????] } > Removal of overlay in a server group fails inside a composite > ------------------------------------------------------------- > > Key: WFCORE-2337 > URL: https://issues.jboss.org/browse/WFCORE-2337 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta8 > > > Removing the overlay of a serverGroup inside a composite operation fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 21:21:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 8 Mar 2017 21:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8324) Missing Elytron integration with Weld SecurityServices In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9431 to WFLY-8324: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8324 (was: JBEAP-9431) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CDI / Weld Security (was: CDI / Weld) (was: Security) Affects Version/s: (was: 7.1.0.DR13) > Missing Elytron integration with Weld SecurityServices > ------------------------------------------------------ > > Key: WFLY-8324 > URL: https://issues.jboss.org/browse/WFLY-8324 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Critical > > [7:34 PM] Brian Stansberry: @StuartDouglas do we need an elytron equivalent to https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/servic... ? > [7:35 PM] Brian Stansberry: a lazy JIRA search didn't reveal any open issue > Jean-Fran?ois Denise left the room > [7:35 PM] Stuart Douglas: we do indeed > [7:39 PM] Brian Stansberry: i've been chasing down uses of SimpleSecurityManagerService.SERVICE_NAME which is why I saw that > [7:44 PM] Brian Stansberry: @StuartDouglas I'll file a JIRA. Unfortunately I have no clue what elytron construct would do the equivalent > [7:45 PM] Stuart Douglas: I am not 100% sure either > [7:45 PM] Stuart Douglas: at the moment it is mapped at either a Web or EJB level > [7:46 PM] Stuart Douglas: Actually I think I know > [7:46 PM] Brian Stansberry: the current stuff is doing thread local lookups > [7:46 PM] Stuart Douglas: It would just be SecurityDomain.getCurrent().getSecurityIdentity() > [7:46 PM] Brian Stansberry: i.e. the picketbox stuff, SimpleSecurityManager > [7:48 PM] Stuart Douglas: If you are going to file a JIRA can you assign it to me? > [7:49 PM] Stuart Douglas: and I can have a look at it after I am done with what I am currently working on -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 21:38:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 8 Mar 2017 21:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6290) XTS does not work with jbossws.undefined.host in WS config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375021#comment-13375021 ] RH Bugzilla Integration commented on WFLY-6290: ----------------------------------------------- Radovan STANCEL changed the Status of [bug 1333968|https://bugzilla.redhat.com/show_bug.cgi?id=1333968] from ASSIGNED to NEW > XTS does not work with jbossws.undefined.host in WS config > ---------------------------------------------------------- > > Key: WFLY-6290 > URL: https://issues.jboss.org/browse/WFLY-6290 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Ivo Studensky > Fix For: 10.2.0.Final > > > XTS uses ServerConfig to initialise it's configuration. However, we should rely on jboss.bind.address instead, because wsdl-host could take "jbossws.undefined.host" as a value. > "jbossws.undefined.host" will cause UnknownHostException, because address rewriting is not executed in XTS. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 21:50:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 8 Mar 2017 21:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375022#comment-13375022 ] Stuart Douglas commented on WFLY-8306: -------------------------------------- It seems unlikely to be an undertow problem, 891 has no special significance for undertow. Do you have a reproducer? > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 22:00:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 8 Mar 2017 22:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8325) Connector module 'authentication-context' attributes should not support expressions and should be capability references if the target resource provides a capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9432 to WFLY-8325: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8325 (was: JBEAP-9432) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) > Connector module 'authentication-context' attributes should not support expressions and should be capability references if the target resource provides a capability > -------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8325 > URL: https://issues.jboss.org/browse/WFLY-8325 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > > The various "authentication-context" attributes added into the connector module for the elytron integration say they support expressions. They shouldn't, as model references should not support expressions as these interfere with model referential integrity checks. > Also, where possible the attribute definitions should be configured as capability references, thus automatically turning on the kernel's referential integrity checks and allowing CLI and HAL value completion. > The latter is only possible for ADs where the containing resource exposes a capability itself. The DS and XA DS resources do. I'm not sure about RAs but I suspect they don't yet. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 22:08:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 8 Mar 2017 22:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2508) Wildfly OpenSSL 1.0.0.Beta7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9434 to WFCORE-2508: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2508 (was: JBEAP-9434) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Wildfly OpenSSL 1.0.0.Beta7 > --------------------------- > > Key: WFCORE-2508 > URL: https://issues.jboss.org/browse/WFCORE-2508 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 8 22:51:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 8 Mar 2017 22:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8326) Enabling statistics on caches shouldn't require reload of server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9435 to WFLY-8326: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8326 (was: JBEAP-9435) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) (was: User Experience) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR7) (was: 7.1.0.DR13) > Enabling statistics on caches shouldn't require reload of server > ---------------------------------------------------------------- > > Key: WFLY-8326 > URL: https://issues.jboss.org/browse/WFLY-8326 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > {noformat} > /subsystem=infinispan/cache-container=ejb/distributed-cache=dist:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true} > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 00:23:00 2017 From: issues at jboss.org (Einat Peretz (JIRA)) Date: Thu, 9 Mar 2017 00:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375031#comment-13375031 ] Einat Peretz commented on WFLY-8306: ------------------------------------ Sorry about that, after looking at this more thoroughly, I found out it is a bug in the soap framework. Thank you for your help. > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 00:49:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 9 Mar 2017 00:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-996) Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context In-Reply-To: References: Message-ID: Bartosz Baranowski created ELY-996: -------------------------------------- Summary: Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context Key: ELY-996 URL: https://issues.jboss.org/browse/ELY-996 Project: WildFly Elytron Issue Type: Bug Reporter: Bartosz Baranowski Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 00:49:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 9 Mar 2017 00:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-996) Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski reassigned ELY-996: -------------------------------------- Assignee: Bartosz Baranowski (was: Darran Lofthouse) > Incorrect class loader is used for loading custom Initial context factory in Elytron dir-context > ------------------------------------------------------------------------------------------------ > > Key: ELY-996 > URL: https://issues.jboss.org/browse/ELY-996 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 02:41:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 9 Mar 2017 02:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas closed WFLY-8306. -------------------------------- Resolution: Rejected > Soap attachments are being truncated when moving from jboss 7 to wildfly9/10 > ---------------------------------------------------------------------------- > > Key: WFLY-8306 > URL: https://issues.jboss.org/browse/WFLY-8306 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Windows > Reporter: Einat Peretz > Assignee: Stuart Douglas > > Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server. > The same deployed application with same client worked fine on Jboss 7.3. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 03:39:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 9 Mar 2017 03:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-956) Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375101#comment-13375101 ] Martin Choma commented on ELY-956: ---------------------------------- Ok. Feel free to close. > Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory > ------------------------------------------------------------------------------------------------------------- > > Key: ELY-956 > URL: https://issues.jboss.org/browse/ELY-956 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static-analysis scan found a synchronization on java.util.concurrent.ConcurrentHashMap object in: > * {{ElytronPolicyConfigurationFactory.getPolicyConfiguration}} > * {{ElytronPolicyConfigurationFactory.inService}} > If policyConfiguration synchronization is concern, it should be enough to synchronize on policyConfiguration object. > > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123208&mergedDefectId=1377483 > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123209&mergedDefectId=1377485 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 03:58:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=) Date: Thu, 9 Mar 2017 03:58:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-760) Code style formatters are not up-to-date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr ?irok? updated DROOLS-760: ------------------------------- Summary: Code style formatters are not up-to-date (was: Code style formatters are not actual) > Code style formatters are not up-to-date > ---------------------------------------- > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zim?nyi > Assignee: Petr ?irok? > Priority: Minor > Labels: reported-by-qe > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 03:59:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=) Date: Thu, 9 Mar 2017 03:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-760) Code style formatters are not up-to-date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375114#comment-13375114 ] Petr ?irok? commented on DROOLS-760: ------------------------------------ My understanding was that this JIRA is mainly about not having up-to-date formatters for IDEs, which I believe got mostly fixed? We can keep this open until _everything_ gets fixed, but that may very well never happen. > Code style formatters are not up-to-date > ---------------------------------------- > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zim?nyi > Assignee: Petr ?irok? > Priority: Minor > Labels: reported-by-qe > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 05:44:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 9 Mar 2017 05:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375189#comment-13375189 ] Mario Fusco commented on DROOLS-1471: ------------------------------------- Sorry but it is impossible for me to investigate and eventually fix this issue without a reproducer. Can you please provide one? Also there's a chance that this issue has been already solved in drools 6.5. Did you give it a try? > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 05:46:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 05:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2509) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-7081 to WFCORE-2509: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2509 (was: WFLY-7081) Component/s: Security (was: Security) Fix Version/s: 3.0.0.Beta8 (was: 11.0.0.Alpha1) > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2509 > URL: https://issues.jboss.org/browse/WFCORE-2509 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 05:47:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 05:47:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2509) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375194#comment-13375194 ] Darran Lofthouse commented on WFCORE-2509: ------------------------------------------ Although reported against the Undertow subsystem I am moving to WFCORE as a change to the Elytron subsystem is required to switch off wrapping of the SSLEngine produced by the SSLContext so Undertow can have direct access to it. > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2509 > URL: https://issues.jboss.org/browse/WFCORE-2509 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 05:55:00 2017 From: issues at jboss.org (Michael Neifeld (JIRA)) Date: Thu, 9 Mar 2017 05:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1472) NPE in stateful session In-Reply-To: References: Message-ID: Michael Neifeld created DROOLS-1472: --------------------------------------- Summary: NPE in stateful session Key: DROOLS-1472 URL: https://issues.jboss.org/browse/DROOLS-1472 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.Final Environment: RedHat 6.2, Java 8.102 Reporter: Michael Neifeld Assignee: Mario Fusco Priority: Critical Found NPE in a log that probably leads to session destroying. CEP works in multithreaded environment and there are almost always 16 drools-workers thread. 2017-03-05 16:30:58 com.mot.ssol.cep.workflow.CEPSession [ERROR] Session execution error occurred java.lang.NullPointerException: null at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:686) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.LeftInputAdapterNode.doInsertSegmentMemory(LeftInputAdapterNode.java:225) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:210) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:169) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:86) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:81) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2105) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1296) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at com.mot.ssol.cep.workflow.CEPSession.run(CEPSession.java:121) ~[mimonitor-cepm-3.0.jar:3.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 06:14:02 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 9 Mar 2017 06:14:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1472) NPE in stateful session In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375225#comment-13375225 ] Mario Fusco commented on DROOLS-1472: ------------------------------------- It's impossible for me to investigate and eventually fix this issue without a reproduce. Please provide one or I cannot do anything else than closing this ticket. > NPE in stateful session > ------------------------ > > Key: DROOLS-1472 > URL: https://issues.jboss.org/browse/DROOLS-1472 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: RedHat 6.2, Java 8.102 > Reporter: Michael Neifeld > Assignee: Mario Fusco > Priority: Critical > > Found NPE in a log that probably leads to session destroying. > CEP works in multithreaded environment and there are almost always 16 drools-workers thread. > 2017-03-05 16:30:58 com.mot.ssol.cep.workflow.CEPSession [ERROR] Session execution error occurred > java.lang.NullPointerException: null > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:686) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertSegmentMemory(LeftInputAdapterNode.java:225) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:210) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:169) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:86) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:81) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2105) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1296) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at com.mot.ssol.cep.workflow.CEPSession.run(CEPSession.java:121) ~[mimonitor-cepm-3.0.jar:3.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 06:47:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 9 Mar 2017 06:47:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8327) Configuring automatic identity outflow causes the source domain to stop working In-Reply-To: References: Message-ID: Bartosz Baranowski created WFLY-8327: ---------------------------------------- Summary: Configuring automatic identity outflow causes the source domain to stop working Key: WFLY-8327 URL: https://issues.jboss.org/browse/WFLY-8327 Project: WildFly Issue Type: Bug Reporter: Bartosz Baranowski Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 06:48:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 9 Mar 2017 06:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8327) Configuring automatic identity outflow causes the source domain to stop working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski reassigned WFLY-8327: ---------------------------------------- Assignee: Bartosz Baranowski (was: Jason Greene) > Configuring automatic identity outflow causes the source domain to stop working > ------------------------------------------------------------------------------- > > Key: WFLY-8327 > URL: https://issues.jboss.org/browse/WFLY-8327 > Project: WildFly > Issue Type: Bug > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 06:48:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 9 Mar 2017 06:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8327) Configuring automatic identity outflow causes the source domain to stop working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski updated WFLY-8327: ------------------------------------- Component/s: Security > Configuring automatic identity outflow causes the source domain to stop working > ------------------------------------------------------------------------------- > > Key: WFLY-8327 > URL: https://issues.jboss.org/browse/WFLY-8327 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 06:51:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 9 Mar 2017 06:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2510) Configuring automatic identity outflow causes the source domain to stop working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski moved WFLY-8327 to WFCORE-2510: -------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2510 (was: WFLY-8327) Component/s: Security (was: Security) > Configuring automatic identity outflow causes the source domain to stop working > ------------------------------------------------------------------------------- > > Key: WFCORE-2510 > URL: https://issues.jboss.org/browse/WFCORE-2510 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 06:59:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 9 Mar 2017 06:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2511) overlay, redeploy-links should ignore unknown deployments In-Reply-To: References: Message-ID: Jean-Francois Denise created WFCORE-2511: -------------------------------------------- Summary: overlay, redeploy-links should ignore unknown deployments Key: WFCORE-2511 URL: https://issues.jboss.org/browse/WFCORE-2511 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Jean-Francois Denise Assignee: ehsavoie Hugonnet When this operation has been first specified, it has been required to fail if the deployment was not existing. That is not right. Linked deployments can be non existing and a pattern can return an empty set of deployments. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 07:09:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 9 Mar 2017 07:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2510) Configuring automatic identity outflow causes the source domain to stop working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2510: ------------------------------------- Description: When you configure an Elytron security domain to automatically outflow identities from it to a different domain, the source domain stops working. How to reproduce: 1. configure management interface to be secured by Elytron ManagementDomain: {noformat} /core-service=management/access=identity:add(security-domain=ManagementDomain) /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade,value={enabled=true, sasl-authentication-factory=management-sasl-authentication}) /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=management-http-authentication) /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) {noformat} 2. configure ManagementDomain to outflow its identity somewhere, eg. ApplicationDomain: {noformat} /subsystem=elytron/security-domain=ManagementDomain:write-attribute(name=outflow-security-domains,value=[ApplicationDomain]) {noformat} 3. Reload the server 4. Try to invoke any operation using CLI, it will fail: {noformat} [standalone at localhost:9990 /] :whoami Failed to perform read-operation-description: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.NullPointerException:null {noformat} > Configuring automatic identity outflow causes the source domain to stop working > ------------------------------------------------------------------------------- > > Key: WFCORE-2510 > URL: https://issues.jboss.org/browse/WFCORE-2510 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > > When you configure an Elytron security domain to automatically outflow identities from it to a different domain, the source domain stops working. > How to reproduce: > 1. configure management interface to be secured by Elytron ManagementDomain: > {noformat} > /core-service=management/access=identity:add(security-domain=ManagementDomain) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade,value={enabled=true, sasl-authentication-factory=management-sasl-authentication}) > /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=management-http-authentication) > /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) > {noformat} > 2. configure ManagementDomain to outflow its identity somewhere, eg. ApplicationDomain: > {noformat} > /subsystem=elytron/security-domain=ManagementDomain:write-attribute(name=outflow-security-domains,value=[ApplicationDomain]) > {noformat} > 3. Reload the server > 4. Try to invoke any operation using CLI, it will fail: > {noformat} > [standalone at localhost:9990 /] :whoami > Failed to perform read-operation-description: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.NullPointerException:null > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 07:25:00 2017 From: issues at jboss.org (Michael Neifeld (JIRA)) Date: Thu, 9 Mar 2017 07:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1472) NPE in stateful session In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375284#comment-13375284 ] Michael Neifeld commented on DROOLS-1472: ----------------------------------------- I really don't know what leads to this exception, but I know that after few hours of work I have a number of such NPEs. Any suggestion how to catch the cause is very appreciated. > NPE in stateful session > ------------------------ > > Key: DROOLS-1472 > URL: https://issues.jboss.org/browse/DROOLS-1472 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: RedHat 6.2, Java 8.102 > Reporter: Michael Neifeld > Assignee: Mario Fusco > Priority: Critical > > Found NPE in a log that probably leads to session destroying. > CEP works in multithreaded environment and there are almost always 16 drools-workers thread. > 2017-03-05 16:30:58 com.mot.ssol.cep.workflow.CEPSession [ERROR] Session execution error occurred > java.lang.NullPointerException: null > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:686) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertSegmentMemory(LeftInputAdapterNode.java:225) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:210) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:169) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:86) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:81) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2105) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1296) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at com.mot.ssol.cep.workflow.CEPSession.run(CEPSession.java:121) ~[mimonitor-cepm-3.0.jar:3.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 07:31:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 9 Mar 2017 07:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2413) Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek closed WFCORE-2413. -------------------------------- Resolution: Won't Fix Problem was in old version of Elytron when I was compiling. Thanks [~michpetrov]. > Using own CustomRealm, CustomModificationRealm and CustomRealmMapper implementation leads to AbstractMethodError. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2413 > URL: https://issues.jboss.org/browse/WFCORE-2413 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > Using own CustomRealm, CustomModifiableRealm and CustomRealmMapper implementation leads to AbstractMethodError. > I tried create my own implementation, set up server to use it but I get error message about AbstractMethodError. > You can see bellow how to reproduce this problem. I attached jar files with implementation where are located .java files too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 07:54:00 2017 From: issues at jboss.org (Michael Neifeld (JIRA)) Date: Thu, 9 Mar 2017 07:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1472) NPE in stateful session In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375313#comment-13375313 ] Michael Neifeld commented on DROOLS-1472: ----------------------------------------- I just walk through the stack trace and have found: {code:java} // Some comments here private static TupleSets getTargetStagedLeftTuples(NetworkNode node, InternalWorkingMemory wm, SegmentMemory smem) { if (node == smem.getTipNode()) { // we are about to process the segment tip, allow it to merge insert/update/delete clashes if ( smem.isEmpty() ) { SegmentUtilities.createChildSegments(wm, smem, ((LeftTupleSource) node).getSinkPropagator() ); } return smem.getFirst().getStagedLeftTuples().takeAll(); } else { return null; } } {code} in class org.drools.core.phreak.RuleNetworkEvaluator. the method was invoked on line 298 {code:java} stagedLeftTuples = getTargetStagedLeftTuples(node, wm, smem); LeftTupleSinkNode sink = ((LeftTupleSource) node).getSinkPropagator().getFirstLeftTupleSink(); trgTuples = evalNode( pmem, node, bit, nodeMem, smems, smemIndex, wm, stack, processRian, executor, srcTuples, smem, stagedLeftTuples, sink ); if ( trgTuples == null ) { break; // Queries exists and has been placed StackEntry, and there are no current trgTuples to process } {code} and if the method will return null we will fail with NPE. > NPE in stateful session > ------------------------ > > Key: DROOLS-1472 > URL: https://issues.jboss.org/browse/DROOLS-1472 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: RedHat 6.2, Java 8.102 > Reporter: Michael Neifeld > Assignee: Mario Fusco > Priority: Critical > > Found NPE in a log that probably leads to session destroying. > CEP works in multithreaded environment and there are almost always 16 drools-workers thread. > 2017-03-05 16:30:58 com.mot.ssol.cep.workflow.CEPSession [ERROR] Session execution error occurred > java.lang.NullPointerException: null > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:686) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertSegmentMemory(LeftInputAdapterNode.java:225) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:210) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:169) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:86) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:81) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2105) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1296) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at com.mot.ssol.cep.workflow.CEPSession.run(CEPSession.java:121) ~[mimonitor-cepm-3.0.jar:3.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 07:55:00 2017 From: issues at jboss.org (Michael Neifeld (JIRA)) Date: Thu, 9 Mar 2017 07:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1472) NPE in stateful session In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375313#comment-13375313 ] Michael Neifeld edited comment on DROOLS-1472 at 3/9/17 7:54 AM: ----------------------------------------------------------------- I just walk through the stack trace and have found: {code:java} private static TupleSets getTargetStagedLeftTuples(NetworkNode node, InternalWorkingMemory wm, SegmentMemory smem) { if (node == smem.getTipNode()) { // we are about to process the segment tip, allow it to merge insert/update/delete clashes if ( smem.isEmpty() ) { SegmentUtilities.createChildSegments(wm, smem, ((LeftTupleSource) node).getSinkPropagator() ); } return smem.getFirst().getStagedLeftTuples().takeAll(); } else { return null; } } {code} in class org.drools.core.phreak.RuleNetworkEvaluator. the method was invoked on line 298 {code:java} stagedLeftTuples = getTargetStagedLeftTuples(node, wm, smem); LeftTupleSinkNode sink = ((LeftTupleSource) node).getSinkPropagator().getFirstLeftTupleSink(); trgTuples = evalNode( pmem, node, bit, nodeMem, smems, smemIndex, wm, stack, processRian, executor, srcTuples, smem, stagedLeftTuples, sink ); if ( trgTuples == null ) { break; // Queries exists and has been placed StackEntry, and there are no current trgTuples to process } {code} and if the method will return null we will fail with NPE. was (Author: newfield): I just walk through the stack trace and have found: {code:java} // Some comments here private static TupleSets getTargetStagedLeftTuples(NetworkNode node, InternalWorkingMemory wm, SegmentMemory smem) { if (node == smem.getTipNode()) { // we are about to process the segment tip, allow it to merge insert/update/delete clashes if ( smem.isEmpty() ) { SegmentUtilities.createChildSegments(wm, smem, ((LeftTupleSource) node).getSinkPropagator() ); } return smem.getFirst().getStagedLeftTuples().takeAll(); } else { return null; } } {code} in class org.drools.core.phreak.RuleNetworkEvaluator. the method was invoked on line 298 {code:java} stagedLeftTuples = getTargetStagedLeftTuples(node, wm, smem); LeftTupleSinkNode sink = ((LeftTupleSource) node).getSinkPropagator().getFirstLeftTupleSink(); trgTuples = evalNode( pmem, node, bit, nodeMem, smems, smemIndex, wm, stack, processRian, executor, srcTuples, smem, stagedLeftTuples, sink ); if ( trgTuples == null ) { break; // Queries exists and has been placed StackEntry, and there are no current trgTuples to process } {code} and if the method will return null we will fail with NPE. > NPE in stateful session > ------------------------ > > Key: DROOLS-1472 > URL: https://issues.jboss.org/browse/DROOLS-1472 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: RedHat 6.2, Java 8.102 > Reporter: Michael Neifeld > Assignee: Mario Fusco > Priority: Critical > > Found NPE in a log that probably leads to session destroying. > CEP works in multithreaded environment and there are almost always 16 drools-workers thread. > 2017-03-05 16:30:58 com.mot.ssol.cep.workflow.CEPSession [ERROR] Session execution error occurred > java.lang.NullPointerException: null > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:686) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertSegmentMemory(LeftInputAdapterNode.java:225) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:210) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:169) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:86) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:81) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2105) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1296) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at com.mot.ssol.cep.workflow.CEPSession.run(CEPSession.java:121) ~[mimonitor-cepm-3.0.jar:3.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 08:12:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 08:12:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration is first. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Summary: Ensure OpenSSL Registration is first. (was: Ensure OpenSSL Registration if first.) > Ensure OpenSSL Registration is first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The following in SecurityRealmResourceDefinition registers the provider: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 08:13:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 9 Mar 2017 08:13:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8323) The datasources and resource-adapters subsystems introduce hard requirements for the legacy security subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-8323: ----------------------------------- Description: There are code paths in the connector module that result in dependencies on services provided by the legacy security subsystem being added to ds and r-a services even though the ds or r-a config doesn't require the depended on services. This will force users to retain the legacy subsystem in their config even though it is otherwise unnecessary. The services are org.jboss.as.security.service.SubjectFactoryService and org.jboss.as.security.service.SimpleSecurityManagerService. was: There are code paths in the connector module that result in dependencies on services provided by the legacy security subsystem being added to ds and r-a services even though the ds or r-a config doesn't require the depended on services. This will force users to retain the legacy subsystem in their config even though it is otherwise unnecessary. The services are org.jboss.as.security.service.SubjectFactoryService and org.jboss.as.security.service.SimpleSecurityManagerService. Related to this, the configuration xml includes some 'elytron-enabled' attributes that appear to be redundant, since 'authentication-context' attributes indicate a need for elytron. I believe resolving the main subject of this JIRA may help clarify whether those attributes are adding value, since a fix will involve analysis of what scenarios indicate a requirement for the legacy security services and what do not. If all those cases can be identified without resorting to the user declaring 'elytron-enabled' that's a good sign that 'elytron-enabled' is not adding value. > The datasources and resource-adapters subsystems introduce hard requirements for the legacy security subsystem > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8323 > URL: https://issues.jboss.org/browse/WFLY-8323 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > > There are code paths in the connector module that result in dependencies on services provided by the legacy security subsystem being added to ds and r-a services even though the ds or r-a config doesn't require the depended on services. This will force users to retain the legacy subsystem in their config even though it is otherwise unnecessary. > The services are org.jboss.as.security.service.SubjectFactoryService and org.jboss.as.security.service.SimpleSecurityManagerService. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 08:16:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 08:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-992) An SSLContext is not required to support a session context. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-992: --------------------------------- Fix Version/s: 1.1.0.Beta29 (was: 1.1.0.Beta30) > An SSLContext is not required to support a session context. > ----------------------------------------------------------- > > Key: ELY-992 > URL: https://issues.jboss.org/browse/ELY-992 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > > Otherwise if we use an SSLContext that does not support it we get a NPE, e.g. with wildfly-openssl: - > {quote}Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:302) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$4.lambda$getValueSupplier$1(SSLDefinitions.java:725) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 08:17:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 08:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-994) Add option to SSLContextBuilder to control if resulting SSLEngine is protected. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-994. ---------------------------------- Resolution: Done > Add option to SSLContextBuilder to control if resulting SSLEngine is protected. > ------------------------------------------------------------------------------- > > Key: ELY-994 > URL: https://issues.jboss.org/browse/ELY-994 > Project: WildFly Elytron > Issue Type: Enhancement > Components: SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 08:22:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 08:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2512) The 'module' attribute on all custom-* resource definitions must be mandatory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved JBEAP-9450 to WFCORE-2512: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2512 (was: JBEAP-9450) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > The 'module' attribute on all custom-* resource definitions must be mandatory > ----------------------------------------------------------------------------- > > Key: WFCORE-2512 > URL: https://issues.jboss.org/browse/WFCORE-2512 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta8 > > > We don't expect custom resources to be loaded from the elytron subsystem module so a module needs to be specified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 08:22:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 08:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2512) The 'module' attribute on all custom-* resource definitions must be mandatory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2512: ------------------------------------- Fix Version/s: 3.0.0.Beta8 > The 'module' attribute on all custom-* resource definitions must be mandatory > ----------------------------------------------------------------------------- > > Key: WFCORE-2512 > URL: https://issues.jboss.org/browse/WFCORE-2512 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta8 > > > We don't expect custom resources to be loaded from the elytron subsystem module so a module needs to be specified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 09:17:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 9 Mar 2017 09:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-997) Elytron form authentication does not store POST data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina moved JBEAP-9455 to ELY-997: --------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-997 (was: JBEAP-9455) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Authentication Mechanisms (was: Security) (was: Web (Undertow)) Affects Version/s: 1.1.0.Beta28 (was: 7.1.0.DR12) > Elytron form authentication does not store POST data > ---------------------------------------------------- > > Key: ELY-997 > URL: https://issues.jboss.org/browse/ELY-997 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.1.0.Beta28 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: authentication, eap71_alpha, form, http, servlet > > Form authentication backed by Elytron in the web applications uses status code 303 (See Other) to redirect user after processing /j_security_check. > We see two serious issues here: > * Legacy security uses status code 302 (Moved Temporarily/Found) to handle this redirect and existing applications/clients may behave differently for these different codes. (e.g. default behavior of Apache HTTP client is to follow redirect for 303, but not to follow for 302) > * The 303 status code was introduced in HTTP 1.1 so it's not part of HTTP 1.0, but the 303 is returned also for HTTP/1.0 request as a HTTP/1.0 response, which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 09:32:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Thu, 9 Mar 2017 09:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1340) NPE when deploying RA adapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka moved JBEAP-9459 to JBJCA-1340: -------------------------------------------- Project: IronJacamar (was: JBoss Enterprise Application Platform) Key: JBJCA-1340 (was: JBEAP-9459) Workflow: classic default workflow (was: CDW with loose statuses v1) Component/s: Deployer (was: JCA) Affects Version/s: WildFly/IronJacamar 1.4.1.Final (was: 7.1.0.DR13) Affects Testing: (was: Regression) > NPE when deploying RA adapter > ----------------------------- > > Key: JBJCA-1340 > URL: https://issues.jboss.org/browse/JBJCA-1340 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Affects Versions: WildFly/IronJacamar 1.4.1.Final > Environment: IronJacamar 1.4.2.Final > Reporter: Martin Simka > Assignee: Stefano Maestri > Priority: Blocker > > commit [b28a11761463de3e316b039675c55864667bf13f|https://github.com/ironjacamar/ironjacamar/commit/b28a11761463de3e316b039675c55864667bf13f] introduced NPE when deploying RA. > There is a lot of failing tests in IronJacamar testsuite, one example is org.jboss.jca.deployers.test.unit.connector16.Ra16Standard303TestCase > issue seems to be [AbstractResourceAdapterDeployer.java#L1658|https://github.com/ironjacamar/ironjacamar/blob/1.4/deployers/src/main/java/org/jboss/jca/deployers/common/AbstractResourceAdapterDeployer.java#L1658] where {{connectionDefinition}} is null in some cases. > There are more issues similar to this one added by later commits for Elytron integration. [AbstractResourceAdapterDeployer.java#L1666|https://github.com/ironjacamar/ironjacamar/blob/1.4/deployers/src/main/java/org/jboss/jca/deployers/common/AbstractResourceAdapterDeployer.java#L1666] will have the same problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 09:36:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 9 Mar 2017 09:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8328) RAR endpoint creation requires too much permission from deployment when security manager is used In-Reply-To: References: Message-ID: Ondra Chaloupka created WFLY-8328: ------------------------------------- Summary: RAR endpoint creation requires too much permission from deployment when security manager is used Key: WFLY-8328 URL: https://issues.jboss.org/browse/WFLY-8328 Project: WildFly Issue Type: Bug Components: Security Manager Affects Versions: 10.1.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor Attachments: getClassLoader-permission-stacktrace.txt When RAR is deployed the EJB endpoint creation requires too much {{RuntimePermission}} to be defined in deployment itself. It's needed to define {code} new RuntimePermission("accessDeclaredMembers") new RuntimePermission("defineClassInPackage.*") new RuntimePermission("getClassLoader") {code} These permissions should not be required as are needed by internal endpoind creation operations launched from {{org.jboss.as.ejb3.inflow.JBossMessageEndpointFactory}} Stacktraces of security manager exceptions are added in attachment. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 09:42:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 9 Mar 2017 09:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8328) RAR endpoint creation requires too much permission from deployment when security manager is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated WFLY-8328: ---------------------------------- Component/s: EJB > RAR endpoint creation requires too much permission from deployment when security manager is used > ------------------------------------------------------------------------------------------------ > > Key: WFLY-8328 > URL: https://issues.jboss.org/browse/WFLY-8328 > Project: WildFly > Issue Type: Bug > Components: EJB, Security Manager > Affects Versions: 10.1.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Attachments: getClassLoader-permission-stacktrace.txt > > > When RAR is deployed the EJB endpoint creation requires too much {{RuntimePermission}} to be defined in deployment itself. It's needed to define > {code} > new RuntimePermission("accessDeclaredMembers") > new RuntimePermission("defineClassInPackage.*") > new RuntimePermission("getClassLoader") > {code} > These permissions should not be required as are needed by internal endpoind creation operations launched from {{org.jboss.as.ejb3.inflow.JBossMessageEndpointFactory}} > Stacktraces of security manager exceptions are added in attachment. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:14:01 2017 From: issues at jboss.org (Rodrigo Veleda (JIRA)) Date: Thu, 9 Mar 2017 10:14:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375458#comment-13375458 ] Rodrigo Veleda commented on WFLY-6916: -------------------------------------- I was struggling with exactly the same issue. I also followed the steps for setting up multiple JSF installations on Wildfly 10. The only difference was that my target mojarra version was 2.1.29-01. Anyway, I've found out that even after setting up multiple JSF installations, it is still necessary to add the following context param to the web.xml: org.jboss.jbossfaces.JSF_CONFIG_NAME mojarra-2.1.29-01 Hope this helps people facing the same issue. Cheers. > Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty > -------------------------------------------------------------------------------------- > > Key: WFLY-6916 > URL: https://issues.jboss.org/browse/WFLY-6916 > Project: WildFly > Issue Type: Bug > Components: JSF > Environment: Wildfly 10 final > Java 8 > Reporter: Prakash Boda > Assignee: Farah Juma > > Below is the stacktrace. > 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services > 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty > 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:219) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:88) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216) > at java.security.AccessController.doPrivileged(Native Method) > at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125) > at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp > at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269) > at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226) > ... 25 more > After this error also deployment is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:18:00 2017 From: issues at jboss.org (Rodrigo Veleda (JIRA)) Date: Thu, 9 Mar 2017 10:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375458#comment-13375458 ] Rodrigo Veleda edited comment on WFLY-6916 at 3/9/17 10:17 AM: --------------------------------------------------------------- I was struggling with exactly the same issue. I also followed the steps for setting up multiple JSF installations on Wildfly 10. The only difference was that my target mojarra version was 2.1.29-01. Anyway, I've found out that even after setting up multiple JSF installations, it is still necessary to add the following context param to the web.xml: org.jboss.jbossfaces.JSF_CONFIG_NAME mojarra-2.1.29-01 Hope this helps people facing the same issue, since this is not mentioned on the document regarding how to set up multiple JSF installations. Cheers. was (Author: rveleda): I was struggling with exactly the same issue. I also followed the steps for setting up multiple JSF installations on Wildfly 10. The only difference was that my target mojarra version was 2.1.29-01. Anyway, I've found out that even after setting up multiple JSF installations, it is still necessary to add the following context param to the web.xml: org.jboss.jbossfaces.JSF_CONFIG_NAME mojarra-2.1.29-01 Hope this helps people facing the same issue. Cheers. > Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty > -------------------------------------------------------------------------------------- > > Key: WFLY-6916 > URL: https://issues.jboss.org/browse/WFLY-6916 > Project: WildFly > Issue Type: Bug > Components: JSF > Environment: Wildfly 10 final > Java 8 > Reporter: Prakash Boda > Assignee: Farah Juma > > Below is the stacktrace. > 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services > 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty > 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:219) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:88) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216) > at java.security.AccessController.doPrivileged(Native Method) > at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125) > at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp > at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269) > at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226) > ... 25 more > After this error also deployment is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:25:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 9 Mar 2017 10:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-997) Elytron form authentication does not store POST data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375468#comment-13375468 ] Jan Kalina commented on ELY-997: -------------------------------- In the end it was very trivial fix - just to call resumeRequst as part of reauth. Just note: testsuite/integration/*web* tests use wildfly build from *servlet-dist* - dont forgot to rebuild to run test against modified elytron! > Elytron form authentication does not store POST data > ---------------------------------------------------- > > Key: ELY-997 > URL: https://issues.jboss.org/browse/ELY-997 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.1.0.Beta28 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: authentication, eap71_alpha, form, http, servlet > > Form authentication backed by Elytron in the web applications uses status code 303 (See Other) to redirect user after processing /j_security_check. > We see two serious issues here: > * Legacy security uses status code 302 (Moved Temporarily/Found) to handle this redirect and existing applications/clients may behave differently for these different codes. (e.g. default behavior of Apache HTTP client is to follow redirect for 303, but not to follow for 302) > * The 303 status code was introduced in HTTP 1.1 so it's not part of HTTP 1.0, but the 303 is returned also for HTTP/1.0 request as a HTTP/1.0 response, which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:27:00 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 10:27:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: mohammed hilout created WFCORE-2513: --------------------------------------- Summary: Wildfly 10.1.0.Final does not start as a linux service Key: WFCORE-2513 URL: https://issues.jboss.org/browse/WFCORE-2513 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 2.2.0.Final Environment: Windows 8/Windows Server 2012 Oracle Java 8 Reporter: mohammed hilout Assignee: Tomaz Cerar Fix For: 2.2.1.CR1, 3.0.0.Alpha6 Wildfly fails to start as a windows service. Installation works fine: {code} .\service.bat install Using the X86-64bit version of prunsrv "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown" Service Wildfly installed {code} Windows reports this error: {quote} Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1. {quote} {code} Event log report: The Wildfly service terminated with the following service-specific error: Incorrect function. 7024 0 2 0 0 0x8080000000000000 196500 System ITPC7.intra.rfgh.net - Wildfly %%1 570069006C00640066006C0079000000 {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:29:01 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Thu, 9 Mar 2017 10:29:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-959) Missing doPrivileged sections in JBossSecurityClient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen resolved SECURITY-959. ------------------------------------- Fix Version/s: PicketBox_5_0_0.Beta1 Resolution: Done The commit that added the necessary privileged blocks to JBossSecurityClient was ported to master and will be part of PicketBox 5.0.0.Beta1 > Missing doPrivileged sections in JBossSecurityClient > ---------------------------------------------------- > > Key: SECURITY-959 > URL: https://issues.jboss.org/browse/SECURITY-959 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_5_0_0.Alpha3 > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: PicketBox_5_0_0.Beta1 > > > There is a regression introduced by recent PicketBox upgrade (part of [1]). With PicketBox 4.9.7[2] it is possible to run {{performSimpleLogin()}} and {{cleanUp()}} methods of {{JBossSecurityClient}} class with security manager enabled. However; running these methods with PicketBox 5.0.0.Alpha3[3] causes AccessControlException. > PicketBox 4.9.7 is in EAP 7.1.0.DR3, PicketBox 5.0.0.Alpha3 in EAP 7.1.0.DR4 and DR5 => regression against 7.1.0.DR3. > This issue was noticed in consequence of an investigation of failed tests in AS TS run with security manager. > Tests that fail on {{performSimpleLogin()}} method: > * org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase#testTaskSubmit > * org.jboss.as.test.integration.ee.concurrent.DefaultManagedExecutorServiceTestCase#testTaskSubmit > * org.jboss.as.test.integration.ee.concurrent.DefaultManagedScheduledExecutorServiceTestCase#testTaskSubmit > * org.jboss.as.test.integration.ee.concurrent.DefaultManagedThreadFactoryTestCase#testTaskSubmit > * org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testAnonymous > * org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testJackInABox > * org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurity > * org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurityNotPropagating > * org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase#testMDBLifecycle > * org.jboss.as.test.integration.ejb.security.singleton.SingletonSecurityTestCase#testInvocationOnSecuredMethodWithCorrectRole > * org.jboss.as.test.integration.ejb.security.singleton.SingletonSecurityTestCase#testInvocationOnSecuredMethodWithInCorrectRole > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=DefaultContextServiceTestCase -Dsecurity.manager}} > {code} > SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase.testTaskSubmit: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.getSecurityContext")" in code source "(vfs:/content/DefaultContextServiceTestCase.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.DefaultContextServiceTestCase.war:main" 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 org.jboss.security.SecurityContextAssociation.getSecurityContext(SecurityContextAssociation.java:145) > at org.jboss.security.client.JBossSecurityClient.performSimpleLogin(JBossSecurityClient.java:77) > at org.jboss.security.client.SecurityClient.login(SecurityClient.java:74) > at org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase.testTaskSubmit(DefaultContextServiceTestCase.java:55) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:243) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:219) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > 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) > {code} > Tests failing on {{cleanUp()}} method: > * org.jboss.as.test.integration.ejb.servlet.ServletUnitTestCase#testEJBServlet > * org.jboss.as.test.integration.ejb.servlet.ServletUnitTestCase#testEJBServletEar > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ServletUnitTestCase -Dsecurity.manager}} > {code} > ERROR [org.jboss.as.test.integration.ejb.servlet.EJBServlet] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.getSecurityContext")" in code source "(vfs:/content/ejb3-servlet.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.ejb3-servlet.war:main" from Service Module Loader") > 15:07:52,122 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejb3-servlet/EJBServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.setSecurityContext")" in code source "(vfs:/content/ejb3-servlet.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.ejb3-servlet.war:main" 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 org.jboss.security.SecurityContextAssociation.setSecurityContext(SecurityContextAssociation.java:124) > at org.jboss.security.client.JBossSecurityClient.cleanUp(JBossSecurityClient.java:95) > at org.jboss.security.client.SecurityClient.logout(SecurityClient.java:86) > at org.jboss.as.test.integration.ejb.servlet.EJBServlet.processRequest(EJBServlet.java:75) > at org.jboss.as.test.integration.ejb.servlet.EJBServlet.doGet(EJBServlet.java:84) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 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) > {code} > [1] https://github.com/wildfly/wildfly-core/pull/1764/files > [2] https://github.com/picketbox/picketbox/blob/v4.9.6.Final/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/client/JBossSecurityClient.java > [3] https://github.com/picketbox/picketbox/blob/5.0.0.Alpha3/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/client/JBossSecurityClient.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:29:01 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 10:29:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohammed hilout updated WFCORE-2513: ------------------------------------ Workaround Description: I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" I can start / stop service, but wildfly don't run on boot was: Workaround / fix is to open service.bat file and locate {{set DESCRIPTION="WildFly Application Server"}} and replace it with {{set DESCRIPTION=WildFly Application Server}} > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: Windows 8/Windows Server 2012 > Oracle Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > Fix For: 2.2.1.CR1, 3.0.0.Alpha6 > > > Wildfly fails to start as a windows service. > Installation works fine: > {code} > .\service.bat install > Using the X86-64bit version of prunsrv > "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown" > Service Wildfly installed > {code} > Windows reports this error: > {quote} > Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1. > {quote} > {code} > Event log report: > The Wildfly service terminated with the following service-specific error: > Incorrect function. > > > > 7024 > 0 > 2 > 0 > 0 > 0x8080000000000000 > > 196500 > > > System > ITPC7.intra.rfgh.net > > > - > > Wildfly > %%1 > 570069006C00640066006C0079000000 > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:29:01 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 10:29:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohammed hilout updated WFCORE-2513: ------------------------------------ Description: I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" I can start / stop service, but wildfly don't run on boot was: Wildfly fails to start as a windows service. Installation works fine: {code} .\service.bat install Using the X86-64bit version of prunsrv "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown" Service Wildfly installed {code} Windows reports this error: {quote} Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1. {quote} {code} Event log report: The Wildfly service terminated with the following service-specific error: Incorrect function. 7024 0 2 0 0 0x8080000000000000 196500 System ITPC7.intra.rfgh.net - Wildfly %%1 570069006C00640066006C0079000000 {code} > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: Windows 8/Windows Server 2012 > Oracle Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > Fix For: 2.2.1.CR1, 3.0.0.Alpha6 > > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:30:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 9 Mar 2017 10:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8328) RAR endpoint creation requires too much permission from deployment when security manager is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated WFLY-8328: ---------------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/150 > RAR endpoint creation requires too much permission from deployment when security manager is used > ------------------------------------------------------------------------------------------------ > > Key: WFLY-8328 > URL: https://issues.jboss.org/browse/WFLY-8328 > Project: WildFly > Issue Type: Bug > Components: EJB, Security Manager > Affects Versions: 10.1.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Attachments: getClassLoader-permission-stacktrace.txt > > > When RAR is deployed the EJB endpoint creation requires too much {{RuntimePermission}} to be defined in deployment itself. It's needed to define > {code} > new RuntimePermission("accessDeclaredMembers") > new RuntimePermission("defineClassInPackage.*") > new RuntimePermission("getClassLoader") > {code} > These permissions should not be required as are needed by internal endpoind creation operations launched from {{org.jboss.as.ejb3.inflow.JBossMessageEndpointFactory}} > Stacktraces of security manager exceptions are added in attachment. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:32:00 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 10:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohammed hilout updated WFCORE-2513: ------------------------------------ Affects Version/s: (was: 2.2.0.Final) > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: Windows 8/Windows Server 2012 > Oracle Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:32:00 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 10:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohammed hilout updated WFCORE-2513: ------------------------------------ Fix Version/s: (was: 2.2.1.CR1) (was: 3.0.0.Alpha6) > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: Windows 8/Windows Server 2012 > Oracle Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:33:00 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 10:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohammed hilout updated WFCORE-2513: ------------------------------------ Environment: Oracle Linux Server release 6.7, Oracle, Java 8 (was: Windows 8/Windows Server 2012 Oracle Java 8) > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: Oracle Linux Server release 6.7, Oracle, Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:33:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Thu, 9 Mar 2017 10:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-963) Release PicketBox 5.0.0.Beta1 In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-963: --------------------------------------- Summary: Release PicketBox 5.0.0.Beta1 Key: SECURITY-963 URL: https://issues.jboss.org/browse/SECURITY-963 Project: PicketBox Issue Type: Task Components: JBossSX, Security-SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:34:00 2017 From: issues at jboss.org (Aaron Ogburn (JIRA)) Date: Thu, 9 Mar 2017 10:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2514) standalone.sh can hang on gc log back up moves In-Reply-To: References: Message-ID: Aaron Ogburn created WFCORE-2514: ------------------------------------ Summary: standalone.sh can hang on gc log back up moves Key: WFCORE-2514 URL: https://issues.jboss.org/browse/WFCORE-2514 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 3.0.0.Beta7 Reporter: Aaron Ogburn Assignee: Aaron Ogburn If it doesn't have proper write access to an existing backupgc.log, standalone.sh will hang. The file mv should use the -f flag. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 10:34:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 9 Mar 2017 10:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375480#comment-13375480 ] Ondra Chaloupka commented on WFLY-8275: --------------------------------------- the fix of this issue consists from these parts WFTC: https://github.com/wildfly/wildfly-transaction-client/pull/17 (Beta19) Narayana: https://github.com/jbosstm/narayana/pull/1144 (5.5.4.Final) Narayana spi: https://github.com/jbosstm/jboss-transaction-spi/pull/23 (7.5.2.Final, not required in fact) WildFly: pre-check https://github.com/jbosstm/jboss-as/pull/69, needs to be created a PR to WFLY upstream > 2PC Inflow transactions don't work for JTA > ------------------------------------------ > > Key: WFLY-8275 > URL: https://issues.jboss.org/browse/WFLY-8275 > Project: WildFly > Issue Type: Bug > Components: JCA, Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction. > In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants. > It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call. > {code} > 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98) > at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) > at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445) > at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Full log attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:17:00 2017 From: issues at jboss.org (mohammed hilout (JIRA)) Date: Thu, 9 Mar 2017 11:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohammed hilout updated WFCORE-2513: ------------------------------------ Affects Version/s: 2.2.0.Final > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: Oracle Linux Server release 6.7, Oracle, Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:22:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 9 Mar 2017 11:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFCORE-2513. --------------------------------- Resolution: Rejected this is OS configuration issue not scripts. especially if it works if started manually. on RHEL / Centos 6, {{chkconfig on }} should enable the service on boot. but it depends on many other factors on the system you have. > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: Oracle Linux Server release 6.7, Oracle, Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:39:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 11:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-998) Update the wrappers around SSLEngine, SSLServerScoket, and SSLSocket to allow client auth requirements to be increased. In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-998: ------------------------------------ Summary: Update the wrappers around SSLEngine, SSLServerScoket, and SSLSocket to allow client auth requirements to be increased. Key: ELY-998 URL: https://issues.jboss.org/browse/ELY-998 Project: WildFly Elytron Issue Type: Bug Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta29 i.e. Allows calls to set need and want to true to pass through. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:41:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Thu, 9 Mar 2017 11:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2379) Synchronize XSD and DMR description of credential-store attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev updated WFCORE-2379: ---------------------------------- Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/444, https://github.com/wildfly-security-incubator/wildfly-core/pull/59 (was: https://github.com/wildfly-security/elytron-subsystem/pull/444) > Synchronize XSD and DMR description of credential-store attributes > ------------------------------------------------------------------ > > Key: WFCORE-2379 > URL: https://issues.jboss.org/browse/WFCORE-2379 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store > > Use XSD description in DMR description, because description in XSD is better for attributes > * provider-name > * providers > * other-providers > * relative-to > * uri (DMR description contains wrong vault://) > For {{type}} attribute use this description in both XSD and DMR: "The credential store type, e.g. KeyStoreCredentialStore" . Now there is mentioned wrongly KeyStorePasswordStore > {code:xml|title=XSD} > > > > The credential store type, e.g. KeyStorePasswordStore. > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:54:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Thu, 9 Mar 2017 11:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-956) Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev closed ELY-956. ----------------------------- Resolution: Won't Fix > Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory > ------------------------------------------------------------------------------------------------------------- > > Key: ELY-956 > URL: https://issues.jboss.org/browse/ELY-956 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static-analysis scan found a synchronization on java.util.concurrent.ConcurrentHashMap object in: > * {{ElytronPolicyConfigurationFactory.getPolicyConfiguration}} > * {{ElytronPolicyConfigurationFactory.inService}} > If policyConfiguration synchronization is concern, it should be enough to synchronize on policyConfiguration object. > > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123208&mergedDefectId=1377483 > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123209&mergedDefectId=1377485 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:55:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Thu, 9 Mar 2017 11:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-956) Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reopened ELY-956: ------------------------------- > Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory > ------------------------------------------------------------------------------------------------------------- > > Key: ELY-956 > URL: https://issues.jboss.org/browse/ELY-956 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static-analysis scan found a synchronization on java.util.concurrent.ConcurrentHashMap object in: > * {{ElytronPolicyConfigurationFactory.getPolicyConfiguration}} > * {{ElytronPolicyConfigurationFactory.inService}} > If policyConfiguration synchronization is concern, it should be enough to synchronize on policyConfiguration object. > > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123208&mergedDefectId=1377483 > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123209&mergedDefectId=1377485 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 11:56:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Thu, 9 Mar 2017 11:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-956) Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev closed ELY-956. ----------------------------- Resolution: Rejected > Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory > ------------------------------------------------------------------------------------------------------------- > > Key: ELY-956 > URL: https://issues.jboss.org/browse/ELY-956 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static-analysis scan found a synchronization on java.util.concurrent.ConcurrentHashMap object in: > * {{ElytronPolicyConfigurationFactory.getPolicyConfiguration}} > * {{ElytronPolicyConfigurationFactory.inService}} > If policyConfiguration synchronization is concern, it should be enough to synchronize on policyConfiguration object. > > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123208&mergedDefectId=1377483 > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490244&defectInstanceId=2123209&mergedDefectId=1377485 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:08:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 9 Mar 2017 12:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2514) standalone.sh can hang on gc log back up moves In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-2514: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1426647 Bugzilla Update: Perform > standalone.sh can hang on gc log back up moves > ---------------------------------------------- > > Key: WFCORE-2514 > URL: https://issues.jboss.org/browse/WFCORE-2514 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta7 > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > > If it doesn't have proper write access to an existing backupgc.log, standalone.sh will hang. The file mv should use the -f flag. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:32:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 9 Mar 2017 12:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2511) overlay, redeploy-links should ignore unknown deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375561#comment-13375561 ] ehsavoie Hugonnet commented on WFCORE-2511: ------------------------------------------- Updating design document > overlay, redeploy-links should ignore unknown deployments > --------------------------------------------------------- > > Key: WFCORE-2511 > URL: https://issues.jboss.org/browse/WFCORE-2511 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: ehsavoie Hugonnet > > When this operation has been first specified, it has been required to fail if the deployment was not existing. That is not right. Linked deployments can be non existing and a pattern can return an empty set of deployments. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:37:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 9 Mar 2017 12:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2511) overlay, redeploy-links should ignore unknown deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet updated WFCORE-2511: -------------------------------------- Description: When this operation has been first specified, it has been required to fail if the deployment was not existing. That is not right. Linked deployments can be non existing and a pattern can return an empty set of deployments. The high level operation from the CLI might pass an unexisting deployment name (taking the one from the overlay link to be created for example) which would break the final operation (aka the built composite from the CLI). was: When this operation has been first specified, it has been required to fail if the deployment was not existing. That is not right. Linked deployments can be non existing and a pattern can return an empty set of deployments. > overlay, redeploy-links should ignore unknown deployments > --------------------------------------------------------- > > Key: WFCORE-2511 > URL: https://issues.jboss.org/browse/WFCORE-2511 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: ehsavoie Hugonnet > > When this operation has been first specified, it has been required to fail if the deployment was not existing. That is not right. Linked deployments can be non existing and a pattern can return an empty set of deployments. > The high level operation from the CLI might pass an unexisting deployment name (taking the one from the overlay link to be created for example) which would break the final operation (aka the built composite from the CLI). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:39:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Thu, 9 Mar 2017 12:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2515) Upgrade PicketBox to 5.0.0.Beta1 In-Reply-To: References: Message-ID: Stefan Guilhen created WFCORE-2515: -------------------------------------- Summary: Upgrade PicketBox to 5.0.0.Beta1 Key: WFCORE-2515 URL: https://issues.jboss.org/browse/WFCORE-2515 Project: WildFly Core Issue Type: Task Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:47:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 9 Mar 2017 12:47:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-157) Write expressions to logging.properties configuration file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375567#comment-13375567 ] James Perkins commented on WFCORE-157: -------------------------------------- I think this needs to be solved sooner rather than later with a guarantee that only the {{jboss.server.log.dir}} property will be resolvable. This property will need to be passed in the {{JAVA_OPTS}} of all scripts so it is seen during the log manager configuration. We also need to ensure the launcher API passes that specific property as a {{JAVA_OPT}} as well. This will need to be documented to note that if users want to pass non guaranteed properties that these properties must be set in the {{*.conf[.bat|.ps1]}} files. > Write expressions to logging.properties configuration file > ---------------------------------------------------------- > > Key: WFCORE-157 > URL: https://issues.jboss.org/browse/WFCORE-157 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > Allow properties that use expressions to write the expression out to the logging.properties configuration file. This allows properties passed in at runtime to affect the initial logging configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:50:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 9 Mar 2017 12:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2516) Changes to the logging subsystem are not persisted to the logging.properties in offline CLI In-Reply-To: References: Message-ID: James Perkins created WFCORE-2516: ------------------------------------- Summary: Changes to the logging subsystem are not persisted to the logging.properties in offline CLI Key: WFCORE-2516 URL: https://issues.jboss.org/browse/WFCORE-2516 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins When using {{embed-server}} within offline CLI changes to the logging subsystem are not persisted to the {{logging.properties}} file. Do note that before we fix this we may want to consider a fix for WFCORE-157. The issue being that offline CLI is likely used to provision a server and that server may be configured in a different location. Since the {{jboss.server.log.dir}} or other {{relative-to}} property will be resolved and written as a fully-qualified path this could be an issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:54:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 9 Mar 2017 12:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-157) Write expressions to logging.properties configuration file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375571#comment-13375571 ] Brian Stansberry commented on WFCORE-157: ----------------------------------------- What requirement does this add to JBDS and other IDEs? > Write expressions to logging.properties configuration file > ---------------------------------------------------------- > > Key: WFCORE-157 > URL: https://issues.jboss.org/browse/WFCORE-157 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > Allow properties that use expressions to write the expression out to the logging.properties configuration file. This allows properties passed in at runtime to affect the initial logging configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 12:56:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Thu, 9 Mar 2017 12:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-956) New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen resolved SECURITY-956. ------------------------------------- Fix Version/s: PicketBox_5_0_0.Beta1 Resolution: Done > New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1 > ---------------------------------------------------------------------------- > > Key: SECURITY-956 > URL: https://issues.jboss.org/browse/SECURITY-956 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_5_0_0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Stefan Guilhen > Fix For: PicketBox_5_0_0.Beta1 > > > In case when LdapExtLoginModule has option rolesCtxDN set to empty string then it has different behavior in EAP 7.0 (PicketBox 4.9.x) and 7.1 (PicketBox 5.0.x). > EAP 7.0 uses empty string as base search for LDAP. > * In case when LDAP server supports empty string search base (e.g. Apache DS allows it) it works as expected, all LDAP tree is searched for roles. > * In case when LDAP server does not support empty string search base (e.g. Active Directory or Red Hat Directory Server) it thrown exception authentication fails. However exception is expected since it is misconfiguration for those LDAP servers. > EAP 7.1 does not search any roles for empty string. That means: > * In case when LDAP server supports empty string search base it does not find any roles. However some roles could be found on that type of LDAP servers. > * In case when LDAP server does not support empty string search base it correctly returns no roles and authentication passes. > From my PoV, behavior from EAP 7.0 is more correct, because it works correctly for LDAP servers where empty string is legal search base. However it can be decided that current EAP 7.1 behavior is intended. In that case please create Release Notes Jira (because it is change in behavior) and close this Jira. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 13:00:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Thu, 9 Mar 2017 13:00:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-963) Release PicketBox 5.0.0.Beta1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen closed SECURITY-963. ----------------------------------- Release Notes Text: PicketBox 5.0.0.Beta1 has been released and is available on Nexus. Resolution: Done > Release PicketBox 5.0.0.Beta1 > ----------------------------- > > Key: SECURITY-963 > URL: https://issues.jboss.org/browse/SECURITY-963 > Project: PicketBox > Issue Type: Task > Components: JBossSX, Security-SPI > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 13:02:02 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 9 Mar 2017 13:02:02 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-157) Write expressions to logging.properties configuration file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375574#comment-13375574 ] James Perkins commented on WFCORE-157: -------------------------------------- I wouldn't think any. The current default in the {{logging.properties}} is: {code} ${jboss.server.log.dir}/server.log {code} Once the logging subsystem is added the {{logging.properties}} gets rewritten with the fully-qualified path. So it should work the same for IDE's unless they do some kind of tweaking to the {{logging.properties}}. The idea will be to write the values like: {code} handler.FILE.fileName=${jboss.server.log.dir:/home/jperkins/servers/wildfly-10.1.0.Final/standalone/log}/server.log {code} The default value will be the last good/known value. But if the property is defined it will use the property value. > Write expressions to logging.properties configuration file > ---------------------------------------------------------- > > Key: WFCORE-157 > URL: https://issues.jboss.org/browse/WFCORE-157 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > Allow properties that use expressions to write the expression out to the logging.properties configuration file. This allows properties passed in at runtime to affect the initial logging configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 13:19:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 9 Mar 2017 13:19:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-157) Write expressions to logging.properties configuration file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375582#comment-13375582 ] Brian Stansberry commented on WFCORE-157: ----------------------------------------- Thanks. > Write expressions to logging.properties configuration file > ---------------------------------------------------------- > > Key: WFCORE-157 > URL: https://issues.jboss.org/browse/WFCORE-157 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > Allow properties that use expressions to write the expression out to the logging.properties configuration file. This allows properties passed in at runtime to affect the initial logging configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 17:09:00 2017 From: issues at jboss.org (Manjunath S Paramesan (JIRA)) Date: Thu, 9 Mar 2017 17:09:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375707#comment-13375707 ] Manjunath S Paramesan commented on DROOLS-1471: ----------------------------------------------- Hi [~mfusco], Please find the eclipse project to reproduce this issue on GitHub: https://github.com/manjunath-sp/drools-marshaller-tester Hope this helps. Thanks, Manjunath > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 17:41:00 2017 From: issues at jboss.org (Daniele Pirola (JIRA)) Date: Thu, 9 Mar 2017 17:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8329) cannot set await-initial-transfer attribute in infinispan configuration In-Reply-To: References: Message-ID: Daniele Pirola created WFLY-8329: ------------------------------------ Summary: cannot set await-initial-transfer attribute in infinispan configuration Key: WFLY-8329 URL: https://issues.jboss.org/browse/WFLY-8329 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Daniele Pirola Assignee: Paul Ferraro Inside wildfly infinispan configuration I can't set attribute {{await-initial-transfer}} even if it's present in Infinispan 8.2.4.Final (see {{org.infinispan.configuration.cache.StateTransferConfiguration}}). This is the subsystem that doesn't work: {{ ... }} There is a workaround to set this attribute at runtime? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 19:24:01 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Thu, 9 Mar 2017 19:24:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8330) Add the ability to support cluster configuration specified in jboss-ejb-client.xml In-Reply-To: References: Message-ID: Farah Juma created WFLY-8330: -------------------------------- Summary: Add the ability to support cluster configuration specified in jboss-ejb-client.xml Key: WFLY-8330 URL: https://issues.jboss.org/browse/WFLY-8330 Project: WildFly Issue Type: Bug Components: EJB Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 19:26:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Thu, 9 Mar 2017 19:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chao Wang reassigned WFLY-6607: ------------------------------- Assignee: Chao Wang (was: Chen Maoqian) > Broadcast/Discovery group is possible to create with just a name > ---------------------------------------------------------------- > > Key: WFLY-6607 > URL: https://issues.jboss.org/browse/WFLY-6607 > Project: WildFly > Issue Type: Bug > Components: JMS, Web Console > Affects Versions: 10.0.0.Final > Reporter: Chen Maoqian > Assignee: Chao Wang > > When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default > user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one) > At this moment it's possible to create broadcast group with just a name which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 19:43:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 19:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2302) Ensure sensitivity CREDENTIAL is only applied to clear-password, add CredentialRef for the referencing attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-2302. -------------------------------------- Resolution: Rejected After further discussion we decided the entire attribute is a credential so the constraint should apply to the whole attribute and not just a portion of it. > Ensure sensitivity CREDENTIAL is only applied to clear-password, add CredentialRef for the referencing attribute. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2302 > URL: https://issues.jboss.org/browse/WFCORE-2302 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta8 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 20:02:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 9 Mar 2017 20:02:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron 1.1.0.Beta20 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-2206. -------------------------------------- Fix Version/s: 3.0.0.Alpha20 (was: 3.0.0.Beta8) Resolution: Done > Upgrade to WildFly Elytron 1.1.0.Beta20 > --------------------------------------- > > Key: WFCORE-2206 > URL: https://issues.jboss.org/browse/WFCORE-2206 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha20 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 9 20:08:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 9 Mar 2017 20:08:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-147) Create an option for the ExtHandler to not close children handlers In-Reply-To: References: Message-ID: James Perkins created LOGMGR-147: ------------------------------------ Summary: Create an option for the ExtHandler to not close children handlers Key: LOGMGR-147 URL: https://issues.jboss.org/browse/LOGMGR-147 Project: JBoss Log Manager Issue Type: Enhancement Reporter: James Perkins Assignee: James Perkins In some environments it may not be desirable for the child handlers to be closed when the parent handler is closed. As an example in WildFly if an {{AsyncHandler}} is added with child handlers, then removed those child handlers can no longer be used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 01:42:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 10 Mar 2017 01:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8331) Fix deployment overlay tests to not hide authentication problems In-Reply-To: References: Message-ID: Josef Cacek created WFLY-8331: --------------------------------- Summary: Fix deployment overlay tests to not hide authentication problems Key: WFLY-8331 URL: https://issues.jboss.org/browse/WFLY-8331 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Josef Cacek The deployment overlay tests in {{testsuite/integration/basic}} module has to be updated. The current implementation hide problems which occur before adding the overlay (as there is another failure in {{finally}} section. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 01:49:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 10 Mar 2017 01:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8331) Fix deployment overlay tests to not hide authentication problems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek reassigned WFLY-8331: --------------------------------- Assignee: Josef Cacek > Fix deployment overlay tests to not hide authentication problems > ---------------------------------------------------------------- > > Key: WFLY-8331 > URL: https://issues.jboss.org/browse/WFLY-8331 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > The deployment overlay tests in {{testsuite/integration/basic}} module has to be updated. The current implementation hide problems which occur before adding the overlay (as there is another failure in {{finally}} section. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 01:50:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 10 Mar 2017 01:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8331) Fix deployment overlay tests to not hide authentication problems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFLY-8331: ------------------------------ Description: The deployment overlay tests in {{testsuite/integration/basic}} module have to be updated. The current implementation hide problems which occur before adding the overlay (as there is another failure in {{finally}} section. (was: The deployment overlay tests in {{testsuite/integration/basic}} module has to be updated. The current implementation hide problems which occur before adding the overlay (as there is another failure in {{finally}} section.) > Fix deployment overlay tests to not hide authentication problems > ---------------------------------------------------------------- > > Key: WFLY-8331 > URL: https://issues.jboss.org/browse/WFLY-8331 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > The deployment overlay tests in {{testsuite/integration/basic}} module have to be updated. The current implementation hide problems which occur before adding the overlay (as there is another failure in {{finally}} section. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 02:45:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Fri, 10 Mar 2017 02:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6542) Fix issues in tests with Security Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reassigned WFLY-6542: ------------------------------- Assignee: (was: Jan Tymel) > Fix issues in tests with Security Manager > ----------------------------------------- > > Key: WFLY-6542 > URL: https://issues.jboss.org/browse/WFLY-6542 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Jan Tymel > > Tracker for all security manager issues in the testsuite -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 03:43:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Fri, 10 Mar 2017 03:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-995) Elytron Audit Logging does not log principal if simple file format is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski reassigned ELY-995: -------------------------------------- Assignee: Bartosz Baranowski > Elytron Audit Logging does not log principal if simple file format is used > -------------------------------------------------------------------------- > > Key: ELY-995 > URL: https://issues.jboss.org/browse/ELY-995 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Assignee: Bartosz Baranowski > Priority: Critical > Attachments: deployment.war > > > _SIMPLE_ format of Elytron Audit Logging does not contain the information about the principal when the authentication is not successful. _JSON_ format contains such piece of information. > Compare _JSON_ format > {noformat} > 3/8/17 3:53 PM,WARNING,{"event":"SecurityAuthenticationFailedEvent","event-time":"3/8/17 3:53 PM","security-identity":{"name":"anonymous","creation-time":"3/8/17 3:53 PM"},"success":false,"principal":"user"} > {noformat} > to _SIMPLE_ format > {noformat} > 3/8/17 3:54 PM,WARNING,event=SecurityAuthenticationFailedEvent,event-time=3/8/17 3:54 PM,security-identity=[name=anonymous,creation-time=3/8/17 3:54 PM],success=false} > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 04:39:00 2017 From: issues at jboss.org (Prakash Boda (JIRA)) Date: Fri, 10 Mar 2017 04:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375828#comment-13375828 ] Prakash Boda commented on WFLY-6916: ------------------------------------ [~rveleda] Good that someone else is also facing similar issue. Do this entry in web.xml fixed this ZipException in your case? If yes then I will give it a try and let you know the outcome. Also let me know if I need to do any other configuration to avoid this ZipException. I am still facing it while my application gets deployed. > Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty > -------------------------------------------------------------------------------------- > > Key: WFLY-6916 > URL: https://issues.jboss.org/browse/WFLY-6916 > Project: WildFly > Issue Type: Bug > Components: JSF > Environment: Wildfly 10 final > Java 8 > Reporter: Prakash Boda > Assignee: Farah Juma > > Below is the stacktrace. > 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services > 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty > 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:219) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:88) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216) > at java.security.AccessController.doPrivileged(Native Method) > at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125) > at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp > at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269) > at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226) > ... 25 more > After this error also deployment is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 04:51:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 10 Mar 2017 04:51:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8332) Create test case for usage PicketBox security domain as Elytron security realm In-Reply-To: References: Message-ID: Ondrej Lukas created WFLY-8332: ---------------------------------- Summary: Create test case for usage PicketBox security domain as Elytron security realm Key: WFLY-8332 URL: https://issues.jboss.org/browse/WFLY-8332 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Ondrej Lukas Assignee: Ondrej Lukas Create test case for usage PicketBox security domain as Elytron security realm -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 04:59:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 10 Mar 2017 04:59:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8131) Aliases in credential stores should be case insensitive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFLY-8131: ------------------------------ Description: Working with credential store aliases should be case insensitive. Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase. E.g. {code} /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password) /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove() {code} *Current behavior:* First command succeeds and the second fails as the alias is changed to "upper" (in lowercase). *Expected behavior:* Both commans succeeds. *Unignore tests* When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. {code} git grep WFLY-8131 {code} was: Working with credential store aliases should be case insensitive. Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase. E.g. {code} /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password) /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove() {code} *Current behavior:* First command succeeds and the second fails as the alias is changed to "upper" (in lowercase). *Expected behavior:* Both commans succeeds. > Aliases in credential stores should be case insensitive > ------------------------------------------------------- > > Key: WFLY-8131 > URL: https://issues.jboss.org/browse/WFLY-8131 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Peter Skopek > Priority: Critical > Labels: credential-store, user_experience > > Working with credential store aliases should be case insensitive. > Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase. > E.g. > {code} > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password) > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove() > {code} > *Current behavior:* > First command succeeds and the second fails as the alias is changed to "upper" (in lowercase). > *Expected behavior:* > Both commans succeeds. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8131 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 05:16:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 10 Mar 2017 05:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-997) Elytron form authentication does not store POST data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated ELY-997: --------------------------- Fix Version/s: 1.1.0.Beta29 > Elytron form authentication does not store POST data > ---------------------------------------------------- > > Key: ELY-997 > URL: https://issues.jboss.org/browse/ELY-997 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.1.0.Beta28 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: authentication, eap71_alpha, form, http, servlet > Fix For: 1.1.0.Beta29 > > > Form authentication backed by Elytron in the web applications uses status code 303 (See Other) to redirect user after processing /j_security_check. > We see two serious issues here: > * Legacy security uses status code 302 (Moved Temporarily/Found) to handle this redirect and existing applications/clients may behave differently for these different codes. (e.g. default behavior of Apache HTTP client is to follow redirect for 303, but not to follow for 302) > * The 303 status code was introduced in HTTP 1.1 so it's not part of HTTP 1.0, but the 303 is returned also for HTTP/1.0 request as a HTTP/1.0 response, which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 05:44:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Fri, 10 Mar 2017 05:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2517) Coverity, Dereference after null check (Elytron subsystem) In-Reply-To: References: Message-ID: Martin Choma created WFCORE-2517: ------------------------------------ Summary: Coverity, Dereference after null check (Elytron subsystem) Key: WFCORE-2517 URL: https://issues.jboss.org/browse/WFCORE-2517 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Coverity found possible dereference of null. In this code {{defaultPolicy}} is checked for null and in next step {{defaultPolicy.equals()}} is called. https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=10578397&defectInstanceId=2572005&mergedDefectId=1407435 {code:java|title=PolicyParser.java} boolean providerFound = defaultPolicy == null; while (reader.hasNext() && reader.nextTag() != END_ELEMENT) { verifyNamespace(reader); String localName = reader.getLocalName(); switch (localName) { // Permission Mapper case JACC_POLICY: providerFound = defaultPolicy.equals(parseJaccPolicy(addPolicy, reader, operations)) || providerFound; break; case CUSTOM_POLICY: providerFound = defaultPolicy.equals(parseCustomPolicy(addPolicy, reader, operations)) || providerFound; break; default: throw unexpectedElement(reader); } } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 05:53:01 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 10 Mar 2017 05:53:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2399) Removing and re-adding alias to credential store leads to Duplicate resource failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFCORE-2399: -------------------------------- Description: When an alias is removed from a credential store and added once more, the {{add}} operation fails with Duplicate resource message. *Unignore tests* When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. {code} git grep WFLY-8144 {code} was:When an alias is removed from a credential store and added once more, the {{add}} operation fails with Duplicate resource message. > Removing and re-adding alias to credential store leads to Duplicate resource failure > ------------------------------------------------------------------------------------ > > Key: WFCORE-2399 > URL: https://issues.jboss.org/browse/WFCORE-2399 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store > > When an alias is removed from a credential store and added once more, the {{add}} operation fails with Duplicate resource message. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8144 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 05:55:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 10 Mar 2017 05:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2455) Empty secret-value is not allowed in credential stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFCORE-2455: -------------------------------- Description: It's not possible to add an entry with empty secret-value into a credential store. Masking the fact the password is empty is a valid scenario. {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add() { "outcome" => "failed", "failure-description" => "WFLYCTL0155: 'secret-value' may not be null", "rolled-back" => true } [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add(secret-value="") { "outcome" => "failed", "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter secret-value. Values must have a minimum length of 1 characters", "rolled-back" => true } {code} *Unignore tests* When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. {code} git grep WFLY-8143 {code} was: It's not possible to add an entry with empty secret-value into a credential store. Masking the fact the password is empty is a valid scenario. {code} [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add() { "outcome" => "failed", "failure-description" => "WFLYCTL0155: 'secret-value' may not be null", "rolled-back" => true } [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add(secret-value="") { "outcome" => "failed", "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter secret-value. Values must have a minimum length of 1 characters", "rolled-back" => true } {code} > Empty secret-value is not allowed in credential stores > ------------------------------------------------------- > > Key: WFCORE-2455 > URL: https://issues.jboss.org/browse/WFCORE-2455 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > Labels: credential-store > > It's not possible to add an entry with empty secret-value into a credential store. > Masking the fact the password is empty is a valid scenario. > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0155: 'secret-value' may not be null", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add(secret-value="") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter secret-value. Values must have a minimum length of 1 characters", > "rolled-back" => true > } > {code} > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8143 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:04:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 10 Mar 2017 06:04:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1473) Create a camel component to integrate the kie-server In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1473: ----------------------------------- Summary: Create a camel component to integrate the kie-server Key: DROOLS-1473 URL: https://issues.jboss.org/browse/DROOLS-1473 Project: Drools Issue Type: Bug Components: integration Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:28:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Fri, 10 Mar 2017 06:28:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8329) cannot set await-initial-transfer attribute in infinispan configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8329: --------------------------------- Issue Type: Feature Request (was: Bug) > cannot set await-initial-transfer attribute in infinispan configuration > ----------------------------------------------------------------------- > > Key: WFLY-8329 > URL: https://issues.jboss.org/browse/WFLY-8329 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Daniele Pirola > Assignee: Paul Ferraro > > Inside wildfly infinispan configuration I can't set attribute {{await-initial-transfer}} even if it's present in Infinispan 8.2.4.Final (see {{org.infinispan.configuration.cache.StateTransferConfiguration}}). > This is the subsystem that doesn't work: > {{ > > > ... > > }} > There is a workaround to set this attribute at runtime? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:31:00 2017 From: issues at jboss.org (Richard Opalka (JIRA)) Date: Fri, 10 Mar 2017 06:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9 modular params propagation to forked processes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Opalka reopened WFCORE-1859: ------------------------------------ No true - there are still tests that are failing if modular JVM args are not propagated to forked processed. I resuscitated the following branch for verification: https://github.com/ropalka/wildfly-core/commits/JDK9 If I exclude the last proposal commit: https://github.com/ropalka/wildfly-core/commit/5d3f4c1f24796b0bfe78d5368eb4cdc8317d13c1 then problematic tests are: {code} wildfly-core/testsuite/domain$> org.jboss.as.test.integration.domain.SimpleDomainControllerMigrationTestCase org.jboss.as.test.integration.domain.ProductInfoUnitTestCase org.jboss.as.test.integration.domain.SlaveSynchronizationTestCase org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase org.jboss.as.test.integration.domain.autoignore.AutoIgnoredResourcesDomainTestCase org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite org.jboss.as.test.integration.domain.suites.FullRbacProviderTestSuite org.jboss.as.test.integration.domain.suites.SimpleRbacProviderTestSuite org.jboss.as.test.integration.domain.suites.CLITestSuite org.jboss.as.test.integration.domain.suites.FullRbacProviderPropertiesRoleMappingTestSuite org.jboss.as.test.integration.domain.suites.DomainTestSuite org.jboss.as.test.integration.domain.OperationTimeoutTestCase org.jboss.as.test.integration.domain.ServerManagementTestCase org.jboss.as.test.integration.domain.DefaultInterfaceOveridingDomainTestCase org.jboss.as.test.integration.domain.AdminOnlyModeTestCase org.jboss.as.test.integration.domain.events.ProcessStateListenerTestCase org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase org.jboss.as.test.integration.domain.LegacyConfigurationChangesTestCase org.jboss.as.test.integration.domain.AdminOnlyPolicyTestCase org.jboss.as.test.integration.domain.ConfigurationChangesTestCase org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase org.jboss.as.test.integration.domain.ReloadWithConfigTestCase org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase org.jboss.as.test.integration.respawn.RespawnHttpTestCase Tests run: 29, Failures: 0, Errors: 25, Skipped: 4 {code} > Investigate and fix JDK9 modular params propagation to forked processes > ----------------------------------------------------------------------- > > Key: WFCORE-1859 > URL: https://issues.jboss.org/browse/WFCORE-1859 > Project: WildFly Core > Issue Type: Sub-task > Components: Server, Test Suite > Reporter: Richard Opalka > Assignee: Tomaz Cerar > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:47:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Fri, 10 Mar 2017 06:47:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8333) Print info message with JGroups version during the EAP startup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-9480 to WFLY-8333: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8333 (was: JBEAP-9480) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: (was: 7.1.0.DR13) > Print info message with JGroups version during the EAP startup > -------------------------------------------------------------- > > Key: WFLY-8333 > URL: https://issues.jboss.org/browse/WFLY-8333 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Right now, no INFO message with JGroups version is logged during EAP startup, which makes difficult to recognize what JGroups version is currently used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:47:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Fri, 10 Mar 2017 06:47:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8333) Print info message with JGroups version during the EAP startup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8333: --------------------------------- Affects Version/s: 10.1.0.Final > Print info message with JGroups version during the EAP startup > -------------------------------------------------------------- > > Key: WFLY-8333 > URL: https://issues.jboss.org/browse/WFLY-8333 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Right now, no INFO message with JGroups version is logged during EAP startup, which makes difficult to recognize what JGroups version is currently used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:48:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Fri, 10 Mar 2017 06:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8333) Print info message with JGroups version during server startup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8333: --------------------------------- Summary: Print info message with JGroups version during server startup (was: Print info message with JGroups version during the EAP startup) > Print info message with JGroups version during server startup > ------------------------------------------------------------- > > Key: WFLY-8333 > URL: https://issues.jboss.org/browse/WFLY-8333 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Right now, no INFO message with JGroups version is logged during EAP startup, which makes difficult to recognize what JGroups version is currently used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 07:22:00 2017 From: issues at jboss.org (Flavia Rainone (JIRA)) Date: Fri, 10 Mar 2017 07:22:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8334) It's not possible to set username and password for datasource in elytron-only configuration In-Reply-To: References: Message-ID: Flavia Rainone created WFLY-8334: ------------------------------------ Summary: It's not possible to set username and password for datasource in elytron-only configuration Key: WFLY-8334 URL: https://issues.jboss.org/browse/WFLY-8334 Project: WildFly Issue Type: Bug Components: JCA Reporter: Flavia Rainone Assignee: Flavia Rainone elytron-only = configuration with elytron subsystem and without security subsystem It's not possible to set username and password for datasource in elytron-only configuration. In elytron-only configuration, attribute elytron-enabled has to be set to true otherwise datasource service fails to start because of dependencies on legacy security services (see JBEAP-8763). But when elytron-enabled=true then it's not possible to use username and password (credential-reference doesn't seem to be taken into account - looks like bug with current behavior). I expect that users will want to use simple username and password even in elytron-only configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 08:25:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Fri, 10 Mar 2017 08:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2517) Coverity, Dereference after null check (Elytron subsystem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2517: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Coverity, Dereference after null check (Elytron subsystem) > ---------------------------------------------------------- > > Key: WFCORE-2517 > URL: https://issues.jboss.org/browse/WFCORE-2517 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Coverity found possible dereference of null. In this code {{defaultPolicy}} is checked for null and in next step {{defaultPolicy.equals()}} is called. > https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=10578397&defectInstanceId=2572005&mergedDefectId=1407435 > {code:java|title=PolicyParser.java} > boolean providerFound = defaultPolicy == null; > while (reader.hasNext() && reader.nextTag() != END_ELEMENT) { > verifyNamespace(reader); > String localName = reader.getLocalName(); > switch (localName) { > // Permission Mapper > case JACC_POLICY: > providerFound = defaultPolicy.equals(parseJaccPolicy(addPolicy, reader, operations)) || providerFound; > break; > case CUSTOM_POLICY: > providerFound = defaultPolicy.equals(parseCustomPolicy(addPolicy, reader, operations)) || providerFound; > break; > default: > throw unexpectedElement(reader); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 08:51:00 2017 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Fri, 10 Mar 2017 08:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection In-Reply-To: References: Message-ID: Radim Vansa created JGRP-2162: --------------------------------- Summary: Failed to send broadcast when opening the connection Key: JGRP-2162 URL: https://issues.jboss.org/browse/JGRP-2162 Project: JGroups Issue Type: Bug Reporter: Radim Vansa Assignee: Bela Ban Attachments: TcpNio2McastTest.java IRC disucssion: {quote} bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. rvansa: reproducible? bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough bela_: I don't think it should go over the limit bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message {quote} I was trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCP_PING with only the first node in hosts list (localhost[7800]) - this causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 08:53:00 2017 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Fri, 10 Mar 2017 08:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Vansa updated JGRP-2162: ------------------------------ Description: IRC discussion: {quote} bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. rvansa: reproducible? bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough bela_: I don't think it should go over the limit bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message {quote} I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): {code:xml} {code} This causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all. was: IRC disucssion: {quote} bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. rvansa: reproducible? bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough bela_: I don't think it should go over the limit bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message {quote} I was trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCP_PING with only the first node in hosts list (localhost[7800]) - this causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all. > Failed to send broadcast when opening the connection > ---------------------------------------------------- > > Key: JGRP-2162 > URL: https://issues.jboss.org/browse/JGRP-2162 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Attachments: TcpNio2McastTest.java > > > IRC discussion: > {quote} > bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. > rvansa: reproducible? > bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" > bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be > rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit > rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough > bela_: I don't think it should go over the limit > bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting > bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message > {quote} > I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): > {code:xml} > > {code} > This causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 08:55:00 2017 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Fri, 10 Mar 2017 08:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Vansa updated JGRP-2162: ------------------------------ Description: IRC discussion: {quote} bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. rvansa: reproducible? bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough bela_: I don't think it should go over the limit bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message {quote} I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): {code:xml} {code} This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore). Note that increasing the timeout in request options does not help. was: IRC discussion: {quote} bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. rvansa: reproducible? bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough bela_: I don't think it should go over the limit bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message {quote} I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): {code:xml} {code} This causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all. > Failed to send broadcast when opening the connection > ---------------------------------------------------- > > Key: JGRP-2162 > URL: https://issues.jboss.org/browse/JGRP-2162 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Attachments: TcpNio2McastTest.java > > > IRC discussion: > {quote} > bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. > rvansa: reproducible? > bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" > bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be > rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit > rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough > bela_: I don't think it should go over the limit > bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting > bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message > {quote} > I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): > {code:xml} > > {code} > This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore). > Note that increasing the timeout in request options does not help. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 09:28:05 2017 From: issues at jboss.org (Rodrigo Veleda (JIRA)) Date: Fri, 10 Mar 2017 09:28:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376053#comment-13376053 ] Rodrigo Veleda commented on WFLY-6916: -------------------------------------- [~boda.prakash] Yes. Adding this entry to the web.xml file fixed the ZipException for me. My issue was exactly the same as yours, assuming you've also followed the steps for setting up multiple JSF-installations within Wildfly 10. Let me know if it works for you as well. > Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty > -------------------------------------------------------------------------------------- > > Key: WFLY-6916 > URL: https://issues.jboss.org/browse/WFLY-6916 > Project: WildFly > Issue Type: Bug > Components: JSF > Environment: Wildfly 10 final > Java 8 > Reporter: Prakash Boda > Assignee: Farah Juma > > Below is the stacktrace. > 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services > 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty > 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:219) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:88) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216) > at java.security.AccessController.doPrivileged(Native Method) > at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125) > at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp > at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269) > at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226) > ... 25 more > After this error also deployment is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 09:29:00 2017 From: issues at jboss.org (Rodrigo Veleda (JIRA)) Date: Fri, 10 Mar 2017 09:29:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376053#comment-13376053 ] Rodrigo Veleda edited comment on WFLY-6916 at 3/10/17 9:28 AM: --------------------------------------------------------------- [~boda.prakash] Yes. Adding this entry to the web.xml file fixed the ZipException for me. My issue was exactly as the same as yours, assuming you've also followed the steps for setting up multiple JSF-installations within Wildfly 10. Let me know if it works for you as well. was (Author: rveleda): [~boda.prakash] Yes. Adding this entry to the web.xml file fixed the ZipException for me. My issue was exactly the same as yours, assuming you've also followed the steps for setting up multiple JSF-installations within Wildfly 10. Let me know if it works for you as well. > Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty > -------------------------------------------------------------------------------------- > > Key: WFLY-6916 > URL: https://issues.jboss.org/browse/WFLY-6916 > Project: WildFly > Issue Type: Bug > Components: JSF > Environment: Wildfly 10 final > Java 8 > Reporter: Prakash Boda > Assignee: Farah Juma > > Below is the stacktrace. > 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services > 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty > 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:219) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:88) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216) > at java.security.AccessController.doPrivileged(Native Method) > at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166) > at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125) > at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841) > at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp > at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269) > at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226) > ... 25 more > After this error also deployment is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 09:33:00 2017 From: issues at jboss.org (Romain Pelisse (JIRA)) Date: Fri, 10 Mar 2017 09:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8335) User should be informed when switching between JDBC and journal store in transactions subsystem In-Reply-To: References: Message-ID: Romain Pelisse created WFLY-8335: ------------------------------------ Summary: User should be informed when switching between JDBC and journal store in transactions subsystem Key: WFLY-8335 URL: https://issues.jboss.org/browse/WFLY-8335 Project: WildFly Issue Type: Enhancement Components: Transactions Affects Versions: 10.1.0.Final Reporter: Romain Pelisse Assignee: Romain Pelisse Priority: Minor Precondition: 'Use journal store' or 'Use JDBC store' was previously set to true. When enabling other type of store, user is not informed about the fact, that only one of those can be set and the previously enabled store is disabled and the new store is enabled without notification. User should be definitely informed about this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:02:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 10 Mar 2017 10:02:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8336) Upgrade Narayana to 5.5.4.Final In-Reply-To: References: Message-ID: Tom Jenkinson created WFLY-8336: ----------------------------------- Summary: Upgrade Narayana to 5.5.4.Final Key: WFLY-8336 URL: https://issues.jboss.org/browse/WFLY-8336 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:06:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 10 Mar 2017 10:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8336) Upgrade Narayana to 5.5.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated WFLY-8336: -------------------------------- Description: https://issues.jboss.org/projects/JBTM/versions/12333853 https://github.com/jbosstm/narayana/compare/5.5.3.Final...5.5.4.Final > Upgrade Narayana to 5.5.4.Final > ------------------------------- > > Key: WFLY-8336 > URL: https://issues.jboss.org/browse/WFLY-8336 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > https://issues.jboss.org/projects/JBTM/versions/12333853 > https://github.com/jbosstm/narayana/compare/5.5.3.Final...5.5.4.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:16:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 10 Mar 2017 10:16:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8337) Distributed web sessions and SFSBs should use SYNC cache mode by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9487 to WFLY-8337: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8337 (was: JBEAP-9487) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR13) > Distributed web sessions and SFSBs should use SYNC cache mode by default > ------------------------------------------------------------------------ > > Key: WFLY-8337 > URL: https://issues.jboss.org/browse/WFLY-8337 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > For SFSBs, ASYNC mode requres pessimistic locking/repeatable read. > In order to use looser locking isolation (since with SFSB, contention is not an issue), SYNC mode is more appropriate as a default. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:17:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 10 Mar 2017 10:17:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: Ingo Weiss created JBJCA-1341: --------------------------------- Summary: Account for additional DB2 FATAL connection errors Key: JBJCA-1341 URL: https://issues.jboss.org/browse/JBJCA-1341 Project: IronJacamar Issue Type: Enhancement Components: Validator Reporter: Ingo Weiss Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:23:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 10 Mar 2017 10:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated JBJCA-1341: ------------------------------ Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/606 > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Original Estimate: 2 days > Remaining Estimate: 2 days > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:23:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 10 Mar 2017 10:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss reassigned JBJCA-1341: --------------------------------- Assignee: Ingo Weiss > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Remaining Estimate: 2 days > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:23:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 10 Mar 2017 10:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss reassigned JBJCA-1341: --------------------------------- Assignee: (was: Ingo Weiss) > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:28:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 10 Mar 2017 10:28:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8338) L1 should be disabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9489 to WFLY-8338: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8338 (was: JBEAP-9489) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR13) > L1 should be disabled by default > -------------------------------- > > Key: WFLY-8338 > URL: https://issues.jboss.org/browse/WFLY-8338 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Our default configuration for web and ejb uses locking reads. This makes L1 completely useless since remote calls to the primary owner would be necessary any time L1 would ever be referenced. Additionally, it incurs the cost of a separate invalidation command per write. > Having it explicitly disabled in the default config makes it too tempting for uses to naively enable it, without knowing the cost. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:34:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 10 Mar 2017 10:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1472) NPE in stateful session In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376107#comment-13376107 ] Mario Fusco commented on DROOLS-1472: ------------------------------------- Those {code}stagedLeftTuples{code} are supposed to be used only at the border of 2 segments of the phreak network and then only if the node is the tip of the segment. In all other case that object shouldn't be dereferenced and when this happens we want to fail fast with a NPE instead of "hiding the dust under the carpet" with a null check and propagate later an error that will be then much harder to track. Now the question is: why in your case drools is trying to use that object even when it shouldn't? This is clearly a bug, but as I said it's quite impossible for me to investigate it without a chance to reproduce it. > NPE in stateful session > ------------------------ > > Key: DROOLS-1472 > URL: https://issues.jboss.org/browse/DROOLS-1472 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: RedHat 6.2, Java 8.102 > Reporter: Michael Neifeld > Assignee: Mario Fusco > Priority: Critical > > Found NPE in a log that probably leads to session destroying. > CEP works in multithreaded environment and there are almost always 16 drools-workers thread. > 2017-03-05 16:30:58 com.mot.ssol.cep.workflow.CEPSession [ERROR] Session execution error occurred > java.lang.NullPointerException: null > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:686) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertSegmentMemory(LeftInputAdapterNode.java:225) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:210) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:169) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:134) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:86) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:81) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2105) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1296) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] > at com.mot.ssol.cep.workflow.CEPSession.run(CEPSession.java:121) ~[mimonitor-cepm-3.0.jar:3.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:42:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 10 Mar 2017 10:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2162: --------------------------- Fix Version/s: 4.0.2 > Failed to send broadcast when opening the connection > ---------------------------------------------------- > > Key: JGRP-2162 > URL: https://issues.jboss.org/browse/JGRP-2162 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 4.0.2 > > Attachments: TcpNio2McastTest.java > > > IRC discussion: > {quote} > bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. > rvansa: reproducible? > bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" > bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be > rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit > rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough > bela_: I don't think it should go over the limit > bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting > bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message > {quote} > I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): > {code:xml} > > {code} > This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore). > Note that increasing the timeout in request options does not help. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 10:52:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 10 Mar 2017 10:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7810) Artemis hangs during failback in remote JCA scenario In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil reopened WFLY-7810: ------------------------------- Reopening this issue as the fix to WFLY-8246 reintroduced the call to `remotingService.isPaused()` that was causing the 10s wait for each connection > Artemis hangs during failback in remote JCA scenario > ---------------------------------------------------- > > Key: WFLY-7810 > URL: https://issues.jboss.org/browse/WFLY-7810 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > Remote JCA scenario: > * There are 3 nodes > * Node 1 and node 2 are Live-Backup pair (replicated HA) > * Node 3 has MDB which remotely connects to node 1 and is able to do failover on node 2 > * During the test, node 1 is killed and started again > Problem occurs when node 1 is started again. Servers are configured to do failback. When node 1 wants to become live again, something goes wrong with connection between node 1 and node 2. On node 1 I can see repeated WARN message \[1\]. Node 2 prints repeatedly WARN message \[2\]. > I can see the same issue also with 7.0.x. We haven't notice this error because the test didn't check state of servers after the failback. > When I modify the test to not deploy MDB on node 3, the test passes without any unusual error. It seems the issue is related to this scenario. > \[1\] > {code} > 09:59:09,197 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 26357508-1826618556)) AMQ222137: Unable to announce backup, retrying: ActiveMQConnec > tionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster] > at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:747) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1] > at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:625) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1] > at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:607) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1] > at org.apache.activemq.artemis.core.server.cluster.BackupManager$BackupConnector$1.run(BackupManager.java:246) [artemis-server-1.5.0.redhat-1.jar:1.5.0.redhat-1] > at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) [artemis-commons-1.5.0.redhat-1.jar:1.5.0.redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111] > {code} > \[2\] > {code} > 10:00:19,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:00:29,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:00:39,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:00:49,246 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:00:59,247 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:01:09,247 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:01:19,248 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:01:29,248 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:01:39,249 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:01:49,249 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:01:59,250 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > 10:02:09,250 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:31:00 2017 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Fri, 10 Mar 2017 11:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri reassigned JBJCA-1341: -------------------------------------- Assignee: Ingo Weiss > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 10 Mar 2017 11:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8339) Upgrade Narayana to 5.5.4.Final In-Reply-To: References: Message-ID: Tom Jenkinson created WFLY-8339: ----------------------------------- Summary: Upgrade Narayana to 5.5.4.Final Key: WFLY-8339 URL: https://issues.jboss.org/browse/WFLY-8339 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson https://issues.jboss.org/projects/JBTM/versions/12333853 https://github.com/jbosstm/narayana/compare/5.5.3.Final...5.5.4.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:39:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 10 Mar 2017 11:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated JBJCA-1341: ------------------------------ Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607 (was: https://github.com/ironjacamar/ironjacamar/pull/606) > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:45:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 11:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-147) Create an option for the ExtHandler to not close children handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-147: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/104, https://github.com/jboss-logging/jboss-logmanager/pull/105 (was: https://github.com/jboss-logging/jboss-logmanager/pull/104) > Create an option for the ExtHandler to not close children handlers > ------------------------------------------------------------------ > > Key: LOGMGR-147 > URL: https://issues.jboss.org/browse/LOGMGR-147 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.6.Final, 2.1.0.Beta1 > > > In some environments it may not be desirable for the child handlers to be closed when the parent handler is closed. As an example in WildFly if an {{AsyncHandler}} is added with child handlers, then removed those child handlers can no longer be used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:45:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 11:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-147) Create an option for the ExtHandler to not close children handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-147: --------------------------------- Fix Version/s: 2.0.6.Final 2.1.0.Beta1 > Create an option for the ExtHandler to not close children handlers > ------------------------------------------------------------------ > > Key: LOGMGR-147 > URL: https://issues.jboss.org/browse/LOGMGR-147 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.6.Final, 2.1.0.Beta1 > > > In some environments it may not be desirable for the child handlers to be closed when the parent handler is closed. As an example in WildFly if an {{AsyncHandler}} is added with child handlers, then removed those child handlers can no longer be used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:51:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 11:51:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting In-Reply-To: References: Message-ID: James Perkins created LOGMGR-148: ------------------------------------ Summary: Support suppressed exceptions in log formatting Key: LOGMGR-148 URL: https://issues.jboss.org/browse/LOGMGR-148 Project: JBoss Log Manager Issue Type: Feature Request Components: core Reporter: David Lloyd Assignee: James Perkins Fix For: 2.0.0.Final In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:52:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 11:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-148: --------------------------------- Fix Version/s: 1.5.7.Final (was: 2.0.0.Final) > Support suppressed exceptions in log formatting > ----------------------------------------------- > > Key: LOGMGR-148 > URL: https://issues.jboss.org/browse/LOGMGR-148 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 1.5.7.Final > > > In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:52:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 11:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-148: --------------------------------- Git Pull Request: (was: https://github.com/jboss-logging/jboss-logmanager/pull/73) > Support suppressed exceptions in log formatting > ----------------------------------------------- > > Key: LOGMGR-148 > URL: https://issues.jboss.org/browse/LOGMGR-148 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 1.5.7.Final > > > In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 11:56:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 11:56:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-148: --------------------------------- Description: In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. This JIRA was created to track a back port of the JDK 7 enhancement to support suppressed exceptions to the 1.5.x branch which requires JDK 6. This will introduce a new requirement that the 1.5 branch will require JDK 7 to compile, but will still work on JDK 6. was:In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. > Support suppressed exceptions in log formatting > ----------------------------------------------- > > Key: LOGMGR-148 > URL: https://issues.jboss.org/browse/LOGMGR-148 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 1.5.7.Final > > > In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. > This JIRA was created to track a back port of the JDK 7 enhancement to support suppressed exceptions to the 1.5.x branch which requires JDK 6. This will introduce a new requirement that the 1.5 branch will require JDK 7 to compile, but will still work on JDK 6. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 12:07:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 10 Mar 2017 12:07:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated JBJCA-1341: ------------------------------ Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607, https://github.com/ironjacamar/ironjacamar/pull/608 (was: https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607) > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 12:38:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 10 Mar 2017 12:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7337) Introduce an authorization SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376205#comment-13376205 ] Michael Musgrove commented on WFLY-7337: ---------------------------------------- [~dmlloyd] This list of requirements refer to state changes in a transactions and in resources. Please could provide more detail about why these are needed (preferably on an event by event basis). Also you say that the list is incomplete, do you have a view about which kind of future event may be of interest. > Introduce an authorization SPI > ------------------------------ > > Key: WFLY-7337 > URL: https://issues.jboss.org/browse/WFLY-7337 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 12:39:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 10 Mar 2017 12:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7337) Introduce an authorization SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376205#comment-13376205 ] Michael Musgrove edited comment on WFLY-7337 at 3/10/17 12:38 PM: ------------------------------------------------------------------ [~dmlloyd] This list of requirements refer to state changes for both transactions and resources. Please could provide more detail about why these are needed (preferably on an event by event basis). Also you say that the list is incomplete, do you have a view about which kind of future event may be of interest. And finally how does this requirement relate to WFTC? was (Author: mmusgrov): [~dmlloyd] This list of requirements refer to state changes in a transactions and in resources. Please could provide more detail about why these are needed (preferably on an event by event basis). Also you say that the list is incomplete, do you have a view about which kind of future event may be of interest. > Introduce an authorization SPI > ------------------------------ > > Key: WFLY-7337 > URL: https://issues.jboss.org/browse/WFLY-7337 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 12:55:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 10 Mar 2017 12:55:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7340) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reopened WFLY-7340: ------------------------------ > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFLY-7340 > URL: https://issues.jboss.org/browse/WFLY-7340 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 12:55:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 10 Mar 2017 12:55:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina moved WFLY-7340 to WFCORE-2518: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2518 (was: WFLY-7340) Component/s: Security (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:01:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 10 Mar 2017 13:01:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2518: ------------------------------- Affects Version/s: 3.0.0.Beta7 > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:05:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 10 Mar 2017 13:05:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-674) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reopened ELY-674: ---------------------------- > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: ELY-674 > URL: https://issues.jboss.org/browse/ELY-674 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:06:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 10 Mar 2017 13:06:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-674) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina resolved ELY-674. ---------------------------- Fix Version/s: 1.1.0.Beta29 Resolution: Done > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: ELY-674 > URL: https://issues.jboss.org/browse/ELY-674 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:18:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:18:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-359) Failure to start the JVM should trigger a management update plan to rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-359: ------------------------------------ Labels: domain_mode (was: ) > Failure to start the JVM should trigger a management update plan to rollback > ---------------------------------------------------------------------------- > > Key: WFCORE-359 > URL: https://issues.jboss.org/browse/WFCORE-359 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Andrig Miller > Labels: domain_mode > > I have come across situations where certain JVM options, typically related to NUMA options, can cause the JVM to segfault. With our domain model, we expose the ability to set the JVM options, so I think this certainly would be a possibility. > So, as we discussed on the Andiamo call today, this type of situation should cause a rollback of the management update plan, if the JVM fails to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:21:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:21:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-359) Failure to start the JVM should trigger a management update plan to rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-359: ------------------------------------ Labels: domain-mode (was: domain_mode) > Failure to start the JVM should trigger a management update plan to rollback > ---------------------------------------------------------------------------- > > Key: WFCORE-359 > URL: https://issues.jboss.org/browse/WFCORE-359 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Andrig Miller > Labels: domain-mode > > I have come across situations where certain JVM options, typically related to NUMA options, can cause the JVM to segfault. With our domain model, we expose the ability to set the JVM options, so I think this certainly would be a possibility. > So, as we discussed on the Andiamo call today, this type of situation should cause a rollback of the management update plan, if the JVM fails to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:23:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-348) review server debug-options configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-348: ------------------------------------ Labels: domain-mode (was: ) > review server debug-options configuration > ----------------------------------------- > > Key: WFCORE-348 > URL: https://issues.jboss.org/browse/WFCORE-348 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Labels: domain-mode > > We need to review the server debug-options configuration, since it's not entirely clear what value is expected. Currently the JVM specific builder is doing additional checks, so that the value passed to the JVM startsWith -X. Which might not be true for all JVMs. > > https://issues.jboss.org/browse/AS7-1606 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:23:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:23:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1146) Research behavior of fork with ProcessBuilder on modern JVMs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1146: ------------------------------------- Labels: domain-mode (was: ) > Research behavior of fork with ProcessBuilder on modern JVMs > ------------------------------------------------------------ > > Key: WFCORE-1146 > URL: https://issues.jboss.org/browse/WFCORE-1146 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: David Lloyd > Labels: domain-mode > > Right now our Process Controller exists for two primary reasons: > # fork() misbehaves for large processes on some OSes, causing leaks or crashes > # if the HC crashes, the PC can respawn it > We have never (afaik) seen #2 happen. We need to verify whether #1 is still true on modern JVMs on the following operating systems: > * Linux > * Solaris > * IBM OSes > * Windows > * BSDs > * Mac OS X > Test by creating processes with large heap and lots of concurrent file descriptor activity while forking to see what happens. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-273: ------------------------------------ Labels: domain-mode (was: ) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Labels: domain-mode > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1147) Eliminate ProcessController In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1147: ------------------------------------- Labels: domain-mode (was: ) > Eliminate ProcessController > --------------------------- > > Key: WFCORE-1147 > URL: https://issues.jboss.org/browse/WFCORE-1147 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: David Lloyd > Labels: domain-mode > > We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:24:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1806) Split DomainModelControllerService into separate services for initializing as a master versus as a slave In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1806: ------------------------------------- Labels: domain-mode (was: ) > Split DomainModelControllerService into separate services for initializing as a master versus as a slave > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1806 > URL: https://issues.jboss.org/browse/WFCORE-1806 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: domain-mode > Fix For: 4.0.0.Beta1 > > > This is an aspect of WFCORE-338, although it's valid in its own right as a conceptually cleaner approach to host controller boot. > Using different services is a prerequisite to WFCORE-338 as it allows those elements of HC behavior to be started/stopped as a DC candidate is elected or unelected. It also makes it feasible to wire in the service that performs the election. > The method that installs the service with MSC will return a Future, with the service setting the future's value at the completion of start(). DMCS during boot can block reading the future, from that confirm that the service completed successfully, and then proceed with the rest of boot. The boolean is basically an ok/not ok signal. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:25:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-338) Auto-promotion of slave HC to master In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-338: ------------------------------------ Labels: domain-mode (was: ) > Auto-promotion of slave HC to master > ------------------------------------ > > Key: WFCORE-338 > URL: https://issues.jboss.org/browse/WFCORE-338 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: domain-mode > > Implement an option for a properly configured slave HC to promote itself to master after acquiring in some controlled manner an exclusive right to act as such. > Analysis (and eventually design) document is at: https://developer.jboss.org/docs/DOC-55491 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:25:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:25:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1882) Deal with WFCORE-1052 functionality in the HA DC case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1882: ------------------------------------- Labels: domain-mode (was: ) > Deal with WFCORE-1052 functionality in the HA DC case > ----------------------------------------------------- > > Key: WFCORE-1882 > URL: https://issues.jboss.org/browse/WFCORE-1882 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Labels: domain-mode > > WFCORE-1052 adds the ability to reload a process to a different config file from what it is currently running. That includes the domain-wide config file if the reloading process is a master HC. > I don't think we want to support this in a WFCORE-338 scenario, as it amounts to a mechanism to force a different domain-wide config into the domain. I think we should have a more specific, controlled mechanism for that. > Once WFCORE-1881 is implemented HostProcessReloadHandler can check LocalHostControllerInfo to see if its running in a CDC. Note that this issue may have implications on the design of WFCORE-1881. That is, it may not be the case that if LHCI.isMaster() is true then LHCI.isCandidateDomainController() is true. Perhaps an HC configured in the EAP 7.0 and earlier style could be a master but not a CDC. For such an HC the WFCORE-1052 functionality could be available. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:26:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-252) Guard domain topology changes with separate locks from the controller lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-252: ------------------------------------ Labels: domain-mode (was: ) > Guard domain topology changes with separate locks from the controller lock > -------------------------------------------------------------------------- > > Key: WFCORE-252 > URL: https://issues.jboss.org/browse/WFCORE-252 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Affects Versions: 1.0.0.Alpha12 > Reporter: Brian Stansberry > Labels: domain-mode > > Look into having a separate lock for the domain topology, and not using the exclusive controller lock to guard it. This requires great care though, as now there will be two separate locks involved in operation execution. We need to be certain that all code paths always acquire them in the same order or we'll be vulnerable to deadlocks. I believe the correct order should be 1) topology lock 2) controller lock. There are relatively few points where a topology lock would be needed, and I believe they are all at the outer edge of operation execution. So it's much simpler to control those points and ensure they always get topology before doing anything that could need the controller lock. > Note it's possible 3 locks will be involved, one for host topology, one for server, and then the controller lock. > Locking order needs to be thought about on a domain-wide basis, not just within a single process! > This task will be more important once the feature discussed at http://lists.jboss.org/pipermail/wildfly-dev/2014-October/003241.html comes in, as that will result in numerous read operations that truly need the domain topology lock. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:26:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:26:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-251) Avoiding unnecessary 2-phase execution of composite operations in a managed domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-251: ------------------------------------ Labels: domain-mode (was: ) > Avoiding unnecessary 2-phase execution of composite operations in a managed domain > ---------------------------------------------------------------------------------- > > Key: WFCORE-251 > URL: https://issues.jboss.org/browse/WFCORE-251 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Affects Versions: 1.0.0.Alpha12 > Reporter: Brian Stansberry > Labels: domain-mode > > When the console sends a composite operation, it is getting routed into the 2-phase domain wide operation path more often than is necessary, resulting in requests for the exclusive controller lock for read-only ops that could be executed on the local process without needing the lock. > Improving this needs to be done carefully, but should be a relatively straightforward change and probably will have the biggest impact on the parent issue, as most of the CRUD screens in the console don't need to invoke ops that involve more than the domain controller. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:26:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:26:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-218: ------------------------------------ Labels: domain-mode (was: ) > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Labels: domain-mode > Attachments: threaddump-1415735255304.tdump > > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:28:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:28:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-397) Provide Unit for JVM configuration elements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-397: ------------------------------------ Labels: domain-mode (was: ) > Provide Unit for JVM configuration elements > ------------------------------------------- > > Key: WFCORE-397 > URL: https://issues.jboss.org/browse/WFCORE-397 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Labels: domain-mode > > Like with any other config element, units for the JVM parameters would be nice. > I.e. instead of encoding it into the string value ("64m") it would be better to split the actual value from unit (value=64, unit=). See the thread subsystem for a reference how this is done in other places -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:29:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:29:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Affects Version/s: domain-mode > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: domain-mode > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Beta8 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:29:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:29:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-343) Trailing forgotten --> does not generate a good error message on host.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-343: ------------------------------------ Affects Version/s: domain-mode > Trailing forgotten --> does not generate a good error message on host.xml > ------------------------------------------------------------------------- > > Key: WFCORE-343 > URL: https://issues.jboss.org/browse/WFCORE-343 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: Jim Tyrrell > Labels: eap6-ux > > This snippet from the host.xml file, note the --> that was forgotten to be removed in the remote line... > > > > > Generates this error message: > [Host Controller] 21:24:51,341 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > Several lines further down...you get this message... > [Host Controller] Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag(). > [Host Controller] at [row,col {unknown-source}]: [44,4] > It would be nice if the first error message in an XML parsing error would just show me the place it failed, along with maybe the prior line. > Less nice would be the 44,4 to be in the first message and break it down as line 44, character 4. More verbosity would be nice. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:29:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:29:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-330) No Spaces Allowed in Host -> Name, but ' do work, odd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-330: ------------------------------------ Affects Version/s: domain-mode > No Spaces Allowed in Host -> Name, but ' do work, odd > ----------------------------------------------------- > > Key: WFCORE-330 > URL: https://issues.jboss.org/browse/WFCORE-330 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: Jim Tyrrell > Labels: eap6-ux > > For some reason spaces do not seem to be allowed, but an Apostrophe seems to be okay. > [Host Controller] 20:56:20,250 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.IllegalArgumentException: JBAS014719: Invalid value specification Jim's Most_Excellent_Domain_Ever_so_here > Would be nice if the error message would kick out what values are acceptable? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:30:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-385) Allow for configuration of respawn policy in host.xml/domain.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-385: ------------------------------------ Labels: domain-mode (was: ) > Allow for configuration of respawn policy in host.xml/domain.xml > ---------------------------------------------------------------- > > Key: WFCORE-385 > URL: https://issues.jboss.org/browse/WFCORE-385 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: ehsavoie Hugonnet > Priority: Minor > Labels: domain-mode > > The server manager currently uses the default respawn policy -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:30:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:30:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1099) Utility to report on differences in domain configuration between domains In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1099: ------------------------------------- Labels: domain-mode (was: ) > Utility to report on differences in domain configuration between domains > ------------------------------------------------------------------------ > > Key: WFCORE-1099 > URL: https://issues.jboss.org/browse/WFCORE-1099 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: > One of the motivations for the domain controller was to help customers manage drift in their JBoss configurations. Because of operational concerns, specifically datacenter isolation, some customers expect to need to run multiple identical domain controllers. They would then still be faced with drift across domain controllers. A utility to detect this drift would be helpful. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:30:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:30:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-81: ----------------------------------- Affects Version/s: domain-mode > Expose address of DC as runtime attributes on the HC > ---------------------------------------------------- > > Key: WFCORE-81 > URL: https://issues.jboss.org/browse/WFCORE-81 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: Heiko Rupp > Assignee: ehsavoie Hugonnet > Labels: rhq > > Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime. > 17:02:31] I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined > [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute > [17:04:13] bstansberry fine with me when I can query the HC for the http port of the DC > [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well > [17:04:51] <+bstansberry> yes please > [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute > 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address > [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:30:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:30:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-355) List servers in a servergroup below /server-group/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-355: ------------------------------------ Affects Version/s: domain-mode > List servers in a servergroup below /server-group/ > ------------------------------------------------------------- > > Key: WFCORE-355 > URL: https://issues.jboss.org/browse/WFCORE-355 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: Heiko Rupp > Labels: rhq > > It would be nice from a consistency standpoint to list the servers of a servergroup in its > api below /server-group/groupname/ - just the names would be enough. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:31:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-312) Taking thread dumps via HC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-312: ------------------------------------ Affects Version/s: domain-mode > Taking thread dumps via HC > -------------------------- > > Key: WFCORE-312 > URL: https://issues.jboss.org/browse/WFCORE-312 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: James Livingston > > It would be useful to be able to gather low-level per-server information such as Java thread dumps. This would best be gathered from the Host Controllers, and be available via the management model. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:31:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-583: ------------------------------------ Affects Version/s: domain-mode > Think about interactive slave domain controller registration. > ------------------------------------------------------------- > > Key: WFCORE-583 > URL: https://issues.jboss.org/browse/WFCORE-583 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave. > As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible. > - Start slave domain controller disconnected. > - Start CLI and connect to slave using local auth. > - Execute join-domain(hostname, port) > At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store. > Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master. > The slave process generates a public and private key and with interaction with the administrator a certificate signing request. > The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave. > The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead. > Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs. > This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation. > Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:31:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:31:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-494) Timestamped GC logs in domain mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-494: ------------------------------------ Labels: domain-mode (was: ) > Timestamped GC logs in domain mode > ---------------------------------- > > Key: WFCORE-494 > URL: https://issues.jboss.org/browse/WFCORE-494 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: James Livingston > Labels: domain-mode > > In standalone mode, you can add "-Xloggc:gc.log.`date +%Y%m%d%H%M%S`" (or Windows equivalent batch scripting) to have timestamped GC logs which is useful to prevent them from being overwritten when a server is restarted. This does not work in domain mode, since JBoss obviously does not process the back-ticks like a shell interpreter. > It would be useful to be able to get time-stamped gc logs in domain mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:35:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1110) Allow addition of HTTP headers to management console responses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-1110. -------------------------------------- Resolution: Out of Date We now set X-Frame-Options "SAMEORIGIN". If something else is also wanted please file a separate JIRA with the specific use case. > Allow addition of HTTP headers to management console responses > -------------------------------------------------------------- > > Key: WFCORE-1110 > URL: https://issues.jboss.org/browse/WFCORE-1110 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: James Livingston > Assignee: Darran Lofthouse > Labels: eap > > It would be useful to be able to add additional HTTP headers to the responses from the web management console, such as X-Frame-Options. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:35:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-298) Provide configuration to define when config changes are pushed to servers in a domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-298: ------------------------------------ Affects Version/s: domain-mode > Provide configuration to define when config changes are pushed to servers in a domain > ------------------------------------------------------------------------------------- > > Key: WFCORE-298 > URL: https://issues.jboss.org/browse/WFCORE-298 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: domain-mode > Reporter: Brian Stansberry > Labels: EAP > > An EAP customer request: > Right now, any changes done via the CLI to an active profile are pushed to all instances immediately. Some go life, some at reload only > While batch mode can be used to bundle a number of changes in one go, there is currently no way to tell individual servers or server-groups when to accept updates or not. > This proposal is to allow a config switch on servergroup level and on individual server level to accept a configuration change selectively: > 1. immediate, the current situation, being the default > 2. at restart only > 3. at explicit being told so, e.g. when a "reload" is ordered > Example: > > the default when the attribute is absent > > > The latter could then be triggered with: > /host=master/server-config=server1:reload > Similar option could be set on servergroup level, with a similar reload command on that level -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:35:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-200) Ability to launch server instances under different Linux cgroups In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-200: ------------------------------------ Labels: domain-mode (was: ) > Ability to launch server instances under different Linux cgroups > ---------------------------------------------------------------- > > Key: WFCORE-200 > URL: https://issues.jboss.org/browse/WFCORE-200 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: Linux specific > Reporter: James Livingston > Labels: domain-mode > > Linux supports 'cgroups' which allows certain limitations to be applied to a group of processes, such as binding to specific CPU cores or apply CPU usage limits. It would be nice to be able to have a server group or specific server to be launched under a different cgroup so that more fine grained limits can be applied than to the whole host. Obviously this would be Linux specific. > If the cgexec command is available, using "cgexec -g cpu:groupname java ..." rather than "java ..." allows the running of the process under a different cpu cgroup. It should be possible to do this now by pointing it to a shell script rather than the actual java executable, and having the script identify the server from arguments, and then invoking the real java executable via cgexec. > The 'cgexec' tool uses the native code cglib, but I believe that if we just need to put processes under a control group, it is very simple - > just write the process ID to /sys/fs/cgroup/HIERARCHY/GROUPNAME/tasks (where HIERARCHY is 'cpu', 'cpu,cpuacct' or other appropriate thing). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:36:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-289) Emit notifications for servers in domain mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-289: ------------------------------------ Labels: domain-mode (was: ) > Emit notifications for servers in domain mode > --------------------------------------------- > > Key: WFCORE-289 > URL: https://issues.jboss.org/browse/WFCORE-289 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Labels: domain-mode > > emit notifications related to server lifecycle in domain mode: > * server-started > * server-stopped > * server-restarted > * server-destroyed > * server-killed > These notifications should be emitted from the corresponding server-config resource (under /host=XXX/server-config=YYY) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:36:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-344) Create operations to view the host and process controller log files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-344: ------------------------------------ Labels: domain-mode (was: ) > Create operations to view the host and process controller log files > ------------------------------------------------------------------- > > Key: WFCORE-344 > URL: https://issues.jboss.org/browse/WFCORE-344 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: James Perkins > Assignee: James Perkins > Labels: domain-mode > > Operations need to exist somewhere so the {{host-controller.log}} and {{process-controller.log}} files can be read with a management operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:36:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-387) Describe inheritance relationships in the resource description metadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-387: ------------------------------------ Labels: domain-mode (was: ) > Describe inheritance relationships in the resource description metadata > ----------------------------------------------------------------------- > > Key: WFCORE-387 > URL: https://issues.jboss.org/browse/WFCORE-387 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > Some elements in the management model have an inheritance relationship with other elements located elsewhere. For example, system properties can be defined as a child of the root domain resource, as a child of a server-group resource, as a child of the root host resource, and as a child of the server-config resource. > The resource description metadata for a resource needs to describe these relationships. It needs to cover the inheritance hierarchy, as well as how any conflicts are resolved (i.e. does the child win, as is the case with system properties and interfaces, or is some sort of merging strategy employed, as is the case with profiles and socket-binding-groups, where the sets of child resources (subsystems and socket-bindings) are merged, provided that the two sets are disjoint. > A factor to include in this metadata is whether the relationship is fixed (i.e. host system-property inherits from server-group) or whether there is some attribute that defines the inheritance (e.g. a profile's that "includes" another profile has an attribute that defines the name of the included profile.) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:36:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-389: ------------------------------------ Labels: EAP domain-mode (was: EAP) > Alllow non persistent configuration(runtime) changes for server groups and domain using CLI > ------------------------------------------------------------------------------------------- > > Key: WFCORE-389 > URL: https://issues.jboss.org/browse/WFCORE-389 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Shay Matasaro > Assignee: Brian Stansberry > Labels: EAP, domain-mode > Fix For: 4.0.0.Beta1 > > > Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan > One example is the ability to disable a mod-cluster context on multiple servers at once. > Since this operation does not affect the persistent server config it is currently not supported. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:37:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-347) Better reporting if a master and slave HC are both launched from the same directory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-347: ------------------------------------ Labels: domain-mode (was: ) > Better reporting if a master and slave HC are both launched from the same directory > ----------------------------------------------------------------------------------- > > Key: WFCORE-347 > URL: https://issues.jboss.org/browse/WFCORE-347 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Labels: domain-mode > > The only symptom at the moment is hangs on startup on the slave as mentioned in AS7-4593. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:37:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:37:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-388) Overall 'server-state' flag on the Host Controller In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-388: ------------------------------------ Labels: domain-mode (was: ) > Overall 'server-state' flag on the Host Controller > -------------------------------------------------- > > Key: WFCORE-388 > URL: https://issues.jboss.org/browse/WFCORE-388 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > This is for consideration; we need to see if it makes sense. > Request is for an attribute on the HC that indicates aggregate 'server-state'. The desire is to know when all servers are available, and thus it is safe to invoke management ops knowing all servers will receive them. > The only reason a server wouldn't receive an op is if it is started in a non-blocking mode, so the server gets its config but then hasn't connected with the HC and therefore won't get update operations. Starting the server in blocking mode will avoid this situation (as could changes to how we start servers, to make it more like how a slave HC registers with the master HC). So, before doing this let's first look at how to reduce/eliminate the use case for it. > Also to consider when looking at this is how to represent servers in things like "restart-required" state in this overall aggregate 'server-state'. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:38:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-333) Provide a management operation to list the servers in a server group (domain mode) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-333: ------------------------------------ Labels: domain-mode (was: ) > Provide a management operation to list the servers in a server group (domain mode) > ---------------------------------------------------------------------------------- > > Key: WFCORE-333 > URL: https://issues.jboss.org/browse/WFCORE-333 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Richard Achmatowicz > Priority: Minor > Labels: domain-mode > > In domain mode, an end user might want to start one or more servers by hand in a named server group. Obtaining the list of servers in a server group is not readily available: the "group" attribute is embedded in server-config, so we have to drill down into every /host=*/server-config=* combination to find out which servers belong to a specific server group. > It would improve the user experience to have an operation which shows which servers are in a given server group. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:38:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:38:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-326) Pushing configuration artifacts to domain servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-326: ------------------------------------ Labels: clustering domain domain-mode (was: clustering domain) > Pushing configuration artifacts to domain servers > ------------------------------------------------- > > Key: WFCORE-326 > URL: https://issues.jboss.org/browse/WFCORE-326 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darragh Sherwin > Priority: Minor > Labels: clustering, domain, domain-mode > > It should be possible to push configurations artifacts like property files, keystores, etc to domain servers from a domain controller and for applications to reference these configuration artifacts in a generic manner. > Weblogic provides this functionality -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:40:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1531) The HC shutdown operation should accept a restart-servers param like reload does In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1531: ------------------------------------- Labels: domain-mode (was: ) > The HC shutdown operation should accept a restart-servers param like reload does > -------------------------------------------------------------------------------- > > Key: WFCORE-1531 > URL: https://issues.jboss.org/browse/WFCORE-1531 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > If a user uses a management op to restart the HC, e.g. one of these: > {code} > [domain at localhost:9990 /] /host=master:shutdown(restart=true) > {"outcome" => "success"} > [domain at localhost:9990 /] shutdown --host=master --restart=true > {code} > then they should also be able to configure restart-servers=false so the servers remain alive and reconnect to the HC when the PC spawns a new one. > Doing "kill -9 " works fine, with the PC spawning a new HC and the servers reconnecting, so it seems the main thing here is adding the parameter and wiring in the mechanicsm such that the ServerInventory doesn't stop the servers. Perhaps the same thing can be done as HostProcessReloadHandler does, using HostRunningModeControl.setRestartMode(). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:40:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1521) Autostart order in domain mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1521: ------------------------------------- Labels: domain-mode (was: ) > Autostart order in domain mode > ------------------------------ > > Key: WFCORE-1521 > URL: https://issues.jboss.org/browse/WFCORE-1521 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Guillermo Gonz?lez de Ag?ero > Labels: domain-mode > > When defining servers in domain mode, they can be marked to be autostarted, but an order of starting cannot be specified (they'll start in parallel). A new option could be added to start one server only after others have already started. A server start would be posponed until all servers with lower order have already finished. > An example use case would be a server that requires some resources of another one (JMS queues for example). > This can be easily achieved with a CLI batch command, but it would be simpler to have it available out of the box. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1415) SensitivityClassification for process lifecycle actions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1415: ------------------------------------- Labels: domain-mode (was: ) > SensitivityClassification for process lifecycle actions > ------------------------------------------------------- > > Key: WFCORE-1415 > URL: https://issues.jboss.org/browse/WFCORE-1415 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Brian Stansberry > Labels: domain-mode > > Add a sensitivity classification that will be applied to all operations that affect process lifecycle (start/stop/shutdown/restart/suspend/resume) at the various levels (host, server, server-group, server-config). Make it possible to restrict such operations to Administrator/SuperUser roles. > Before anyone starts work on this, discuss with [~harald.pehl] to ensure there's a plan in place for dealing with any impact on the console. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1318) Create an Azure equivalent to the S3 variant of Domain Controller discovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1318: ------------------------------------- Labels: domain-mode (was: ) > Create an Azure equivalent to the S3 variant of Domain Controller discovery > --------------------------------------------------------------------------- > > Key: WFCORE-1318 > URL: https://issues.jboss.org/browse/WFCORE-1318 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > WildFly Core includes an analogoue to JGroups's S3_PING discovery protocol that can be used for slave discovery of the DC on Amazon's EC2 cloud. See https://developer.jboss.org/people/fjuma/blog/2013/03/15/a-domain-controller-discovery-system-for-as-8 for details. > This JIRA is to create an equivalent for Azure. Should use the same configuration style as what Farah did for S3 (generic classname + module + properties; no strongly typed schema.) > Anyone working on this should contact [~rhusar] early in the process, as he has done work on an Azure equivalent to S3_PING for use in JGroups channels. Ping me too for preliminary discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-938) Embedded host controller doesn't support --admin-mode=false option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-938: ------------------------------------ Labels: domain-mode (was: ) > Embedded host controller doesn't support --admin-mode=false option > ------------------------------------------------------------------ > > Key: WFCORE-938 > URL: https://issues.jboss.org/browse/WFCORE-938 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Affects Versions: 2.0.0.Beta4 > Reporter: Petr Kremensky > Assignee: Ken Wills > Labels: domain-mode > > Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default). > * *true* > ** only start services related to server administration > ** do not start other services or accept end user requests. > ** embedded instance will not be visible to remote management clients > * *false* > ** all services are started > ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console) > Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:42:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-710: ------------------------------------ Labels: domain-mode (was: ) > Make ServerOperationResolver handle deployment-overlays similarly to deployments > -------------------------------------------------------------------------------- > > Key: WFCORE-710 > URL: https://issues.jboss.org/browse/WFCORE-710 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.Alpha2 > Reporter: Kabir Khan > Labels: domain-mode > > Currently in domain mode a > {code} > /deployment-overlay=xxx:add(...) > {code} > results in a deployment overlay on ALL servers. > However for deployments > {code} > /deployment=xxx:add(...) > {code} > does not get pushed to the servers. This happens when it is associated with a server group: > {code} > /server-group=zzz/deployment=xxx:add(...) > {code} > Similarly > {code} > /deployment-overlay=xxx:add(...) > {code} > should not get pushed to the servers, until we have a > {code} > /server-group=zzz/deployment=yyy:add(...) > {code} > which picks out the servers we want to have the overlay -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:42:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-817) Reflect suspend state in server-config resource, similar to server resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-817: ------------------------------------ Labels: domain-mode (was: ) > Reflect suspend state in server-config resource, similar to server resource > ----------------------------------------------------------------------------- > > Key: WFCORE-817 > URL: https://issues.jboss.org/browse/WFCORE-817 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Assignee: Ken Wills > Labels: domain-mode > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:42:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:42:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-377: ------------------------------------ Labels: cli domain domain-mode management (was: cli domain management) > The management API should provide a command to restart only all servers that are in state 'reload-required' > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-377 > URL: https://issues.jboss.org/browse/WFCORE-377 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Wolf-Dieter Fink > Labels: cli, domain, domain-mode, management > Fix For: 4.0.0.Beta1 > > > After configuration changes via CLI batch it might be that different processes needs to be restarted. > It is possible to iterate over all servers and check it. > But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state > - at domain level > - at host level > - at server level > command example : > :restart(ifRequired=true) > :reload(ifRequired=true) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:43:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2066) Kill and destroy operations on the server-group In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2066: ------------------------------------- Labels: domain-mode (was: ) > Kill and destroy operations on the server-group > ----------------------------------------------- > > Key: WFCORE-2066 > URL: https://issues.jboss.org/browse/WFCORE-2066 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Labels: domain-mode > > The server-config resources expose kill and destroy operations; it would be useful to have these on the server-group as well. If some problem (e.g. a bad deployment) is causing all servers in the group to hang it is nice to be able to kill/destroy them in one op versus having to identify all members and kill them individually. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:43:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:43:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3) Host Controller should check for and react to changes in its directory-grouping setting when starting servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-3: ---------------------------------- Labels: domain-mode (was: ) > Host Controller should check for and react to changes in its directory-grouping setting when starting servers > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3 > URL: https://issues.jboss.org/browse/WFCORE-3 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > If a user changes the /host=x directory-grouping setting after an HC has already launched servers, when those servers get restarted their data/ dir will be in a new location and any content in the old location will be lost. It would be nice if the HC could detect this situation and try to migrate the data to the new location. > Something like: > 1) See if there is an existing data/ dir at the expected location per the current directory-grouping setting. > 2) If yes, done. > 3) If no, work out what the expected location would be per the other valid directory-grouping settings. (Should only be one alternative, but this algorithm doesn't assume that will remain the case.) > 3) If there is one and only one such location that has an existing data/ dir, copy its contents to the new location. > 4) If there is more than one such location, log a WARN. > 5) If there is a problem copying the contents, log an ERROR, remove whatever partial bits were successfully copied and proceed on. (An alternative is to fail to start the server and force the user to deal with the situation.) > This is borderline minor as this is an edge case. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:45:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:45:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-405: ------------------------------------ Labels: domain-mode (was: ) > Filesystem deployment scanner for a managed domain > -------------------------------------------------- > > Key: WFCORE-405 > URL: https://issues.jboss.org/browse/WFCORE-405 > Project: WildFly Core > Issue Type: Enhancement > Components: Deployment Scanner, Domain Management > Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final > Reporter: hitesh yadav > Labels: domain-mode > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node. > For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group ..... > Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group ............. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:45:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:45:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-405: ------------------------------------ Issue Type: Feature Request (was: Enhancement) > Filesystem deployment scanner for a managed domain > -------------------------------------------------- > > Key: WFCORE-405 > URL: https://issues.jboss.org/browse/WFCORE-405 > Project: WildFly Core > Issue Type: Feature Request > Components: Deployment Scanner, Domain Management > Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final > Reporter: hitesh yadav > Labels: domain-mode > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node. > For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group ..... > Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group ............. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:45:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-291) Handle mixed-domain transformation use cases involving splitting out new subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-291: ------------------------------------ Labels: domain-mode (was: ) > Handle mixed-domain transformation use cases involving splitting out new subsystems > ----------------------------------------------------------------------------------- > > Key: WFCORE-291 > URL: https://issues.jboss.org/browse/WFCORE-291 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > This may end up needing subtasks. > We need to be able to handle the mixed-domain transformation issues that arise when a subsystem is split out from a previously existing subsystem. > 1) The registering slave will have no version info for the new subsystem. The new subsystem needs to be able to register a transformer for the logical equivalent of the 'null' version. > 2) It needs to be possible to register a discard for the root resource of a subsystem. For example, when jsf was split out, the presence of the subsystem was equivalent to the default behavior of the legacy 'web' subsystem, so jsf could just be discarded. > 3) It needs to be possible for one subsystem to issue a reject transformation if the another subsystem is not configured. For example, when jsf was split out it would have been valid for a reject transformation to have been applied by web if the jsf subsystem was not present, since the legacy slave will have jsf. (It's ok this reject wasn't done; I'm just using jsf/web as an example.) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:46:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-81: ----------------------------------- Affects Version/s: (was: domain-mode) > Expose address of DC as runtime attributes on the HC > ---------------------------------------------------- > > Key: WFCORE-81 > URL: https://issues.jboss.org/browse/WFCORE-81 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Assignee: ehsavoie Hugonnet > Labels: domain-mode, rhq > > Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime. > 17:02:31] I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined > [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute > [17:04:13] bstansberry fine with me when I can query the HC for the http port of the DC > [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well > [17:04:51] <+bstansberry> yes please > [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute > 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address > [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:46:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:46:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-81: ----------------------------------- Labels: domain-mode rhq (was: rhq) > Expose address of DC as runtime attributes on the HC > ---------------------------------------------------- > > Key: WFCORE-81 > URL: https://issues.jboss.org/browse/WFCORE-81 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Assignee: ehsavoie Hugonnet > Labels: domain-mode, rhq > > Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime. > 17:02:31] I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined > [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute > [17:04:13] bstansberry fine with me when I can query the HC for the http port of the DC > [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well > [17:04:51] <+bstansberry> yes please > [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute > 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address > [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Affects Version/s: (was: domain-mode) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron, domain-mode > Fix For: 3.0.0.Beta8 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-583: ------------------------------------ Labels: domain-mode (was: ) > Think about interactive slave domain controller registration. > ------------------------------------------------------------- > > Key: WFCORE-583 > URL: https://issues.jboss.org/browse/WFCORE-583 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: domain-mode > Fix For: 4.0.0.Beta1 > > > We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave. > As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible. > - Start slave domain controller disconnected. > - Start CLI and connect to slave using local auth. > - Execute join-domain(hostname, port) > At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store. > Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master. > The slave process generates a public and private key and with interaction with the administrator a certificate signing request. > The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave. > The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead. > Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs. > This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation. > Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Labels: affects_elytron domain-mode (was: affects_elytron) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron, domain-mode > Fix For: 3.0.0.Beta8 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-583: ------------------------------------ Affects Version/s: (was: domain-mode) > Think about interactive slave domain controller registration. > ------------------------------------------------------------- > > Key: WFCORE-583 > URL: https://issues.jboss.org/browse/WFCORE-583 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: domain-mode > Fix For: 4.0.0.Beta1 > > > We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave. > As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible. > - Start slave domain controller disconnected. > - Start CLI and connect to slave using local auth. > - Execute join-domain(hostname, port) > At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store. > Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master. > The slave process generates a public and private key and with interaction with the administrator a certificate signing request. > The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave. > The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead. > Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs. > This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation. > Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-355) List servers in a servergroup below /server-group/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-355: ------------------------------------ Affects Version/s: (was: domain-mode) > List servers in a servergroup below /server-group/ > ------------------------------------------------------------- > > Key: WFCORE-355 > URL: https://issues.jboss.org/browse/WFCORE-355 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Labels: domain-mode, rhq > > It would be nice from a consistency standpoint to list the servers of a servergroup in its > api below /server-group/groupname/ - just the names would be enough. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-355) List servers in a servergroup below /server-group/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-355: ------------------------------------ Labels: domain-mode rhq (was: rhq) > List servers in a servergroup below /server-group/ > ------------------------------------------------------------- > > Key: WFCORE-355 > URL: https://issues.jboss.org/browse/WFCORE-355 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Rupp > Labels: domain-mode, rhq > > It would be nice from a consistency standpoint to list the servers of a servergroup in its > api below /server-group/groupname/ - just the names would be enough. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-343) Trailing forgotten --> does not generate a good error message on host.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-343: ------------------------------------ Affects Version/s: (was: domain-mode) > Trailing forgotten --> does not generate a good error message on host.xml > ------------------------------------------------------------------------- > > Key: WFCORE-343 > URL: https://issues.jboss.org/browse/WFCORE-343 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Labels: domain-mode, eap6-ux > > This snippet from the host.xml file, note the --> that was forgotten to be removed in the remote line... > > > > > Generates this error message: > [Host Controller] 21:24:51,341 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > Several lines further down...you get this message... > [Host Controller] Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag(). > [Host Controller] at [row,col {unknown-source}]: [44,4] > It would be nice if the first error message in an XML parsing error would just show me the place it failed, along with maybe the prior line. > Less nice would be the 44,4 to be in the first message and break it down as line 44, character 4. More verbosity would be nice. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-343) Trailing forgotten --> does not generate a good error message on host.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-343: ------------------------------------ Labels: domain-mode eap6-ux (was: eap6-ux) > Trailing forgotten --> does not generate a good error message on host.xml > ------------------------------------------------------------------------- > > Key: WFCORE-343 > URL: https://issues.jboss.org/browse/WFCORE-343 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Labels: domain-mode, eap6-ux > > This snippet from the host.xml file, note the --> that was forgotten to be removed in the remote line... > > > > > Generates this error message: > [Host Controller] 21:24:51,341 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > Several lines further down...you get this message... > [Host Controller] Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag(). > [Host Controller] at [row,col {unknown-source}]: [44,4] > It would be nice if the first error message in an XML parsing error would just show me the place it failed, along with maybe the prior line. > Less nice would be the 44,4 to be in the first message and break it down as line 44, character 4. More verbosity would be nice. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-330) No Spaces Allowed in Host -> Name, but ' do work, odd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-330: ------------------------------------ Affects Version/s: (was: domain-mode) > No Spaces Allowed in Host -> Name, but ' do work, odd > ----------------------------------------------------- > > Key: WFCORE-330 > URL: https://issues.jboss.org/browse/WFCORE-330 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Labels: domain-mode, eap6-ux > > For some reason spaces do not seem to be allowed, but an Apostrophe seems to be okay. > [Host Controller] 20:56:20,250 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.IllegalArgumentException: JBAS014719: Invalid value specification Jim's Most_Excellent_Domain_Ever_so_here > Would be nice if the error message would kick out what values are acceptable? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:49:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-330) No Spaces Allowed in Host -> Name, but ' do work, odd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-330: ------------------------------------ Labels: domain-mode eap6-ux (was: eap6-ux) > No Spaces Allowed in Host -> Name, but ' do work, odd > ----------------------------------------------------- > > Key: WFCORE-330 > URL: https://issues.jboss.org/browse/WFCORE-330 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Jim Tyrrell > Labels: domain-mode, eap6-ux > > For some reason spaces do not seem to be allowed, but an Apostrophe seems to be okay. > [Host Controller] 20:56:20,250 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.IllegalArgumentException: JBAS014719: Invalid value specification Jim's Most_Excellent_Domain_Ever_so_here > Would be nice if the error message would kick out what values are acceptable? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:50:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-298) Provide configuration to define when config changes are pushed to servers in a domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-298: ------------------------------------ Affects Version/s: (was: domain-mode) > Provide configuration to define when config changes are pushed to servers in a domain > ------------------------------------------------------------------------------------- > > Key: WFCORE-298 > URL: https://issues.jboss.org/browse/WFCORE-298 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: EAP, domain-mode > > An EAP customer request: > Right now, any changes done via the CLI to an active profile are pushed to all instances immediately. Some go life, some at reload only > While batch mode can be used to bundle a number of changes in one go, there is currently no way to tell individual servers or server-groups when to accept updates or not. > This proposal is to allow a config switch on servergroup level and on individual server level to accept a configuration change selectively: > 1. immediate, the current situation, being the default > 2. at restart only > 3. at explicit being told so, e.g. when a "reload" is ordered > Example: > > the default when the attribute is absent > > > The latter could then be triggered with: > /host=master/server-config=server1:reload > Similar option could be set on servergroup level, with a similar reload command on that level -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:50:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-312) Taking thread dumps via HC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-312: ------------------------------------ Labels: domain-mode (was: ) > Taking thread dumps via HC > -------------------------- > > Key: WFCORE-312 > URL: https://issues.jboss.org/browse/WFCORE-312 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: James Livingston > Labels: domain-mode > > It would be useful to be able to gather low-level per-server information such as Java thread dumps. This would best be gathered from the Host Controllers, and be available via the management model. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:50:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-298) Provide configuration to define when config changes are pushed to servers in a domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-298: ------------------------------------ Labels: EAP domain-mode (was: EAP) > Provide configuration to define when config changes are pushed to servers in a domain > ------------------------------------------------------------------------------------- > > Key: WFCORE-298 > URL: https://issues.jboss.org/browse/WFCORE-298 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: EAP, domain-mode > > An EAP customer request: > Right now, any changes done via the CLI to an active profile are pushed to all instances immediately. Some go life, some at reload only > While batch mode can be used to bundle a number of changes in one go, there is currently no way to tell individual servers or server-groups when to accept updates or not. > This proposal is to allow a config switch on servergroup level and on individual server level to accept a configuration change selectively: > 1. immediate, the current situation, being the default > 2. at restart only > 3. at explicit being told so, e.g. when a "reload" is ordered > Example: > > the default when the attribute is absent > > > The latter could then be triggered with: > /host=master/server-config=server1:reload > Similar option could be set on servergroup level, with a similar reload command on that level -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:50:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:50:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-312) Taking thread dumps via HC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-312: ------------------------------------ Affects Version/s: (was: domain-mode) > Taking thread dumps via HC > -------------------------- > > Key: WFCORE-312 > URL: https://issues.jboss.org/browse/WFCORE-312 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: James Livingston > Labels: domain-mode > > It would be useful to be able to gather low-level per-server information such as Java thread dumps. This would best be gathered from the Host Controllers, and be available via the management model. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:52:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:52:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1801) DomainSlaveHostRegistrations should survive a reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1801: ------------------------------------- Labels: domain-mode (was: ) > DomainSlaveHostRegistrations should survive a reload > ---------------------------------------------------- > > Key: WFCORE-1801 > URL: https://issues.jboss.org/browse/WFCORE-1801 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Labels: domain-mode > > DomainSlaveHostRegistrations is used by the master to record HC registration/unregistration events for display via the management API. The lifecycle of this data is tied to that of DomainModelControllerService, which gets gc'd and recreated on each reload. This data should have a longer lifespan than that. > It doesn't need to be persistent (survive HC restart) but surviving reload would be better. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:53:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1923) Add configuration option to make the HTTP management interface unavailable on non-master HCs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1923: ------------------------------------- Labels: domain-mode (was: ) > Add configuration option to make the HTTP management interface unavailable on non-master HCs > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1923 > URL: https://issues.jboss.org/browse/WFCORE-1923 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > This is a sub-requirement of WFCORE-338 and shouldn't be included independent of that without prior discussion. > If a user has a group of candidate domain controllers, a classic way of providing a consistent URL for management clients in the face of changes in the elected DC is to front the set of candidates with a reverse proxy. But for that to work well, the proxy should only see one working HC at a time. For that to happen, we need the non-elected HCs to not open a listener on the HTTP management interface unless they are elected. > Since users may not want this behavior (e.g. if they don't have a reverse proxy set up and thus will get no benefit), this needs to be configurable. > Note that if users elect to use this function they will need to set up a native-management interface to handle the intra-domain traffic. > An open question is whether the interface should not be available at all or whether it should just be that certain contexts are not available. > Also worth some thought before proceeding with this is thinking about how a mod_cluster proxy would be integrated. Doing the mod_cluster integration is out of scope for this task, but it makes sense to think about it a bit so we don't go down a path that will make later mod_cluster work harder. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:53:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1879) Master HC should reject registration attempts by slaves that have any management API version greater than its own In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1879: ------------------------------------- Labels: domain-mode (was: ) > Master HC should reject registration attempts by slaves that have any management API version greater than its own > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1879 > URL: https://issues.jboss.org/browse/WFCORE-1879 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Labels: domain-mode > > (Note: It's possible we already do this, or that somehow we effectively do due to things blowing up if the rule is broken.) > We have always had a rule that the DC must be running the latest version of the software. If it isn't it can't reliably manage slaves as it cannot know how the slaves will interpret the operations it sends to them, and slaves will assume that the master is sending operations that are tailored to the management API versions it sent when it registered. > I do not believe the software actually enforces this requirement though. With the more complex use cases that WFCORE-338 will introduce we need to make this more formal. > When a slave first contacts a master it provides its kernel API version with the HostInfo data it sends over and then later in the registration process it provides the subsystem API versions for all the extensions the master provided. Both of these points provide an opportunity for version comparison. > When an HC rejects registration by a slave, we have a mechanism for propogating an error code to the slave to help it understand and report the problem (e.g. the remote HC is not master or it is running in admin-only mode.) We should try to expand that mechanism to include this case, rather than failing with a general unspecified error. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:53:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:53:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1880) Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1880: ------------------------------------- Labels: domain-mode (was: ) > Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1880 > URL: https://issues.jboss.org/browse/WFCORE-1880 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Labels: domain-mode > > Conceptually related to WFCORE-1879, but here the case is a slave that is already registered handling an /extension=foo:add operation sent by the master. It's theoretically possible that the slave might be running an earlier or equal version of all extensions that were configured when it registered, but for this new "foo" extension it has a newer version. If this happens the add operation should fail. The extension cannot be configured while the domain topology is like this. > Note if the slave is ignoring the extension add op, that is fine. > It's possible this is already somewhat handled. If an extension is added, for transformation to work properly the slave has to send back management API information that the master can use going forward. It's possible though that even that is not being done, which would be a bug. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:54:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2073) Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2073: ------------------------------------- Labels: domain-mode (was: ) > Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2073 > URL: https://issues.jboss.org/browse/WFCORE-2073 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Labels: domain-mode > Fix For: 4.0.0.Alpha1 > > > The ManagedProcess kill() method relies on a scan of running processes that have a command line with -D[] in the command line, refusing to do the OS kill if > 1 such process is found. > This is troublesome if you have > 1 HC on the machine, as they are likely to use the same process names (e.g. "Server:server-one"). So the 'kill' doesn't happen, and destroy() gets used instead. Destroy doesn't seem as strong, as it seems to not prevent shutdown hook execution, leaving open the possibility of hangs. > Perhaps the PC could generate a random int or even a short and include that as a param on the command line as well, then use that as part of the discrimination check. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:54:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 13:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2073) Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2073: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 > Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2073 > URL: https://issues.jboss.org/browse/WFCORE-2073 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Labels: domain-mode > Fix For: 4.0.0.Alpha1 > > > The ManagedProcess kill() method relies on a scan of running processes that have a command line with -D[] in the command line, refusing to do the OS kill if > 1 such process is found. > This is troublesome if you have > 1 HC on the machine, as they are likely to use the same process names (e.g. "Server:server-one"). So the 'kill' doesn't happen, and destroy() gets used instead. Destroy doesn't seem as strong, as it seems to not prevent shutdown hook execution, leaving open the possibility of hangs. > Perhaps the PC could generate a random int or even a short and include that as a param on the command line as well, then use that as part of the discrimination check. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 13:54:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 13:54:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2519) Upgrade jboss-logmanager from 2.0.5.Final to 2.0.6.Final In-Reply-To: References: Message-ID: James Perkins created WFCORE-2519: ------------------------------------- Summary: Upgrade jboss-logmanager from 2.0.5.Final to 2.0.6.Final Key: WFCORE-2519 URL: https://issues.jboss.org/browse/WFCORE-2519 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins An upgrade to the log manager will be required to resolve WFCORE-1585. An enhancement was made as part of LOGMGR-147 to allow child handlers to not be closed when the parent handler is closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:32:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1883) Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1883: ------------------------------------- Labels: domain-mode (was: ) > Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out > ---------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1883 > URL: https://issues.jboss.org/browse/WFCORE-1883 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: domain-mode > > As part of WFCORE-338, a Candidate Domain Controller can shift between acting a master or acting as slave without requiring a reload or reboot. > However, after initial boot, a DCC can be handling management requests. Any transition between acting as a master or slave to the other role must ensure that in-process management requests are not disrupted and that no new management requests are able to access the management model or runtime services until the transition is complete. As a practical matter this likely means that the transition task(s) must acquire the exclusive management lock and hold it until the transition is complete. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:32:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:32:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376248#comment-13376248 ] Brian Stansberry commented on WFCORE-91: ---------------------------------------- git grep "toLowerCase()" shows this in non-test code: cli/src/main/java/org/jboss/as/cli/handlers/CommandTimeoutHandler.java: VALUES.add(tr.name().toLowerCase()); cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to match on the current local. host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLowerCase()) : null; host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk = hashKey.toLowerCase(); server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); server/src/main/java/org/jboss/as/server/operations/AbstractInstallationReporter.java: if (osName != null && osName.toLowerCase().contains("linux")) { > Review use of Locale in toLowerCase() calls > ------------------------------------------- > > Key: WFCORE-91 > URL: https://issues.jboss.org/browse/WFCORE-91 > Project: WildFly Core > Issue Type: Task > Components: CLI, Domain Management > Reporter: Brian Stansberry > > There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed: > {code} > $ git grep "toLowerCase()" > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress > domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc > domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor > host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo > host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase(); > server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + " > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow > testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:33:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1881) Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1881: ------------------------------------- Labels: domain-mode (was: ) > Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible > -------------------------------------------------------------------------------------- > > Key: WFCORE-1881 > URL: https://issues.jboss.org/browse/WFCORE-1881 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Labels: domain-mode > > The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC. > I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable. > Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster(): > 1) ProfileCloneHandler > 2) IgnoredDomainResourceRegistry -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:33:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:33:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1940) Propagate a persistent domain config revision number and time stamp around the domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1940: ------------------------------------- Labels: domain-mode (was: ) > Propagate a persistent domain config revision number and time stamp around the domain > ------------------------------------------------------------------------------------- > > Key: WFCORE-1940 > URL: https://issues.jboss.org/browse/WFCORE-1940 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: domain-mode > > This is a subtask of WFCORE-338 and should not be done independent of that overall work. > The election algorithm we are planning for WFCORE-338 depends on tracking the revision number for changes to the persistent domain-wide model (i.e. what gets written to domain.xml). The revision number will be a simple counter, but we will also track a revision timestamp. The timestamp is solely meant to be an aid to users in understanding when a revision occurred and is not itself relevant to the election algorithm > Task here is to > 1) Read the revision # and timestamp from domain.xml when it is parsed > 2) Increment it locally on any HC when an operation updates the domain-wide persistent config. > 3) Persist the local values in domain.xml whenever an operation updates the domain-wide persistent config. > 4) For the master HC, propagate its current revision # and timestamp along with any multistep write operations pushed to slave HCs. > 5) For the master HC, propagate its current revision # and timestamp along with the resource model data provided to newly connected HCs. > 6) For slave HCs, use the revision # and timestamp provided by the master via 4) and 5) as the base value before incrementing in 2). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:34:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-185) Api returns internal server error instead of not found for non-existing path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-185: ------------------------------------ Labels: domain-mode rhq (was: rhq) > Api returns internal server error instead of not found for non-existing path > ---------------------------------------------------------------------------- > > Key: WFCORE-185 > URL: https://issues.jboss.org/browse/WFCORE-185 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Rupp > Assignee: Brian Stansberry > Labels: domain-mode, rhq > Fix For: 4.0.0.Beta1 > > > When I try to e.g. /subsystem=foo:read-resource the api returns a 500 internal server error. > In http-land, the return code for "not found" is normally 404. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:34:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:34:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-199) Domain graceful shutdown may attempt to use an AbstractMessageHandler that is shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-199: ------------------------------------ Labels: domain-mode (was: ) > Domain graceful shutdown may attempt to use an AbstractMessageHandler that is shutdown > -------------------------------------------------------------------------------------- > > Key: WFCORE-199 > URL: https://issues.jboss.org/browse/WFCORE-199 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Brian Stansberry > Labels: domain-mode > > ManagedServer during shutdown tries to send a "shutdown" op to the remote server, triggering a graceful suspend. > Problem is, the TransactionalProtocolClient it uses is using a ManagementChannelHandler that may have been shut down. The service that controls the lifecycle of the ManagementChannelHandler (i.e. ManagementChannelOpenListenerService) is written to ensure that it isn't shutdown open until incoming requests complete, but there is nothing preventing shutdown when client uses are desired. > The specific area where this can be a problem is the assert !shutdown at > https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/ActiveOperationSupport.java#L151 > One possible solution is to distinguish locally initiated active operations from remote ones. AIUI the goal is to reject further remote ones. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:35:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:35:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-255) Boot time only system properties should not modify the runtime only the model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-255: ------------------------------------ Labels: domain-mode (was: ) > Boot time only system properties should not modify the runtime only the model > ----------------------------------------------------------------------------- > > Key: WFCORE-255 > URL: https://issues.jboss.org/browse/WFCORE-255 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: James Perkins > Labels: domain-mode > > The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. They cannot be set as a system-property resource, but can be overridden via {{JAVA_OPTS}} or the command line. For a domain server these values need to be allowed to be set as a {{boot-time=true}} system property. > The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state. > {code} > [domain at localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log") > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", > "rolled-back" => true, > "server-groups" => {"main-server-group" => {"host" => {"master" => { > "server-one" => {"response" => { > "outcome" => "failed", > "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", > > "rolled-back" => true > }}, > "server-two" => {"response" => { > "outcome" => "failed", > "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", > "rolled-back" => true > }} > }}}} > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:39:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 10 Mar 2017 14:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8340) Resuming a batch job after server resume requires the anonymous identity to have RunAsPrincipalPermission of the original user In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved JBEAP-9493 to WFLY-8340: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8340 (was: JBEAP-9493) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Batch Security (was: Batch) (was: Security) > Resuming a batch job after server resume requires the anonymous identity to have RunAsPrincipalPermission of the original user > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8340 > URL: https://issues.jboss.org/browse/WFLY-8340 > Project: WildFly > Issue Type: Bug > Components: Batch, Security > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Attachments: jbeap9452reproducer.zip > > > - Batch job is submitted by user A > - While the job is running, the server gets suspended > - When user B calls the {{resume}} operation, the Batch execution is attempted to be restarted. However, this only works if anonymous identity has the permission {{org.wildfly.security.auth.permission.RunAsPrincipalPermission}} for user A, which is not the case in the default configuration. > I find this a UX issue because you have to add a special permission to make this work when it should work out-of-the-box, and also one might not want to give this permission to {{anonymous}} because it could be potentially abused in other places. > {noformat} > 14:59:53,729 TRACE [org.wildfly.security] (management-handler-thread - 4) Permission mapping: identity [anonymous] with roles [] implies ("org.wildfly.security.auth.permission.RunAsPrincipalPermission" "user1") = false > 14:19:53,842 ERROR [org.wildfly.extension.batch] (management-handler-thread - 4) WFLYBATCH000016: Failed to restart execution 1 for job server-suspend on deployment server-suspend.war: org.wildfly.security.authz.AuthorizationFailureException: ELY01088: Attempting to run as "user1" authorization operation failed > at org.wildfly.security.auth.server.SecurityIdentity.createRunAsIdentity(SecurityIdentity.java:628) > at org.wildfly.security.auth.server.SecurityIdentity.createRunAsIdentity(SecurityIdentity.java:603) > at org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.privilegedRunAs(JobOperatorService.java:520) > at org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.restartStoppedJobs(JobOperatorService.java:495) > at org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.resume(JobOperatorService.java:430) > at org.jboss.as.server.suspend.SuspendController.resume(SuspendController.java:127) > at org.jboss.as.server.operations.ServerResumeHandler$1$1.handleResult(ServerResumeHandler.java:79) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1493) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1475) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1437) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1410) > at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1284) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:856) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:842) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:748) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:258) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:39:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Fri, 10 Mar 2017 14:39:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-60) Test - In-Reply-To: References: Message-ID: Matt Mahoney created HAWKULARQE-60: -------------------------------------- Summary: Test - Key: HAWKULARQE-60 URL: https://issues.jboss.org/browse/HAWKULARQE-60 Project: Hawkular QE Issue Type: Task Reporter: Matt Mahoney Assignee: mfoley user -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:40:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Fri, 10 Mar 2017 14:40:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-60) Test - In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney deleted HAWKULARQE-60: ----------------------------------- > Test - > ------- > > Key: HAWKULARQE-60 > URL: https://issues.jboss.org/browse/HAWKULARQE-60 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: mfoley user > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-622) DomainOperationContext transformation assumes slave host and slave host's servers receive the same ops In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-622: ------------------------------------ Labels: domain-mode (was: ) > DomainOperationContext transformation assumes slave host and slave host's servers receive the same ops > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-622 > URL: https://issues.jboss.org/browse/WFCORE-622 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > https://github.com/wildfly/wildfly-core/commit/f5c516f2#diff-dc2038399fc72656590c09fe73305791R151 assumes that the result transformer for the host request is appropriate for use with the subsequent requests to that host's servers during domain rollout. > That's a shaky supposition, as the server ops generated from a host request have no fixed relationship to the host request itself. Alignment is the norm but not a rule. In particular it can faill apart with composite ops where some steps in the composite are not relevant to all hosts. > Without this extra transformation, test at [1] fails. This indicates the server op is not getting the transformation registered at [2] applied. But if it's not getting the result transformation applied, wouldn't that mean relevant operation transformation isn't being applied as well? > [1] https://github.com/wildfly/wildfly-core/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/suites/OperationTransformationTestCase.java#L226 > [2] https://github.com/wildfly/wildfly-core/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/extension/VersionedExtension2.java#L108 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-616) Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-616. ------------------------------------- Resolution: Out of Date Looks like the WFCORE-401 work corrected that > Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-616 > URL: https://issues.jboss.org/browse/WFCORE-616 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Brian Stansberry > > The "execute-for-coordinator" header is used internally in domain-wide operation execution to indicate that a call is being made on behalf of the DC. End users should not be able to use it. > Client calls that go through the native handling (including HTTP upgrade) have any such header stripped by ModelControllerClientOperationHandler.ExecuteRequestHandler. We need to do the same thing in the domain-http code for non-upgrade HTTP calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-624) Result transformation for composite op failures is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-624: ------------------------------------ Labels: domain-mode (was: ) > Result transformation for composite op failures is broken > --------------------------------------------------------- > > Key: WFCORE-624 > URL: https://issues.jboss.org/browse/WFCORE-624 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta2 > Reporter: Brian Stansberry > Labels: domain-mode > > CompositeOperationTransformer.CompositeResultTransformer works by analyzing the "step-x" entries in the remote response's "result" node, and then transforming that node. > This breaks down when the failure actually occurs in the remote CompositeOperationHandler, as will be the case if the step refers to a resource or operation that is undefined on that node. In that case there is no "result" node with steps, just a top level failure. > CompositeResultTransformer will actually add a "result" node with the expected error message in this case, but that basically works by luck. And the high level error message for the overall op will no be transformed. > Possible improvements: > 1) CompositeOperationHandler sets up a result node in this case, so CompositeResultTransformer can process it. > 2) CompositeResultTransformer can try and fix up the top level error message as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:41:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-665) When host jvm name and server jvm name are same then the host jvm settings are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-665: ------------------------------------ Labels: domain-mode (was: ) > When host jvm name and server jvm name are same then the host jvm settings are ignored > -------------------------------------------------------------------------------------- > > Key: WFCORE-665 > URL: https://issues.jboss.org/browse/WFCORE-665 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta5 > Environment: All > Reporter: Jay SenSharma > Assignee: Brian Stansberry > Labels: domain-mode > > - If the "host.xml" has the following JVM name defined > {code} > > > > > > > > > > > > > {code} > - If the server refers to the above JVM name as following: > {code} > > > > > > {code} > - In above case when the server-one is booted that time it takes the value from "server-group" (in this case main-server-group) defined in the domain.xml > {code} > > > > > > {code} > So the JVM settings defined for JVM name "Test" is overridden by server-group values: > {code} > 30201 jboss-modules.jar -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on -D[Server:server-one] -XX:PermSize=128m -XX:MaxPermSize=128m -Xms64m -Xmx512m -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djboss.home.dir=/wildfly-9.0.0.CR1-SNAPSHOT -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.log.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/log -Djboss.server.temp.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/tmp -Djboss.server.data.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/data -Dlogging.configuration=file:/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/data/logging.properties > {code} > *NOTICE* the JVM runtime value is -Xms64m -Xmx512m, where as it was supposed to be -Xms300m -Xmx2500m as that is the "Test" jvm setting. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:44:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1005) HostControllerConnectionService does not let in flight requests clear before stopping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1005: ------------------------------------- Labels: domain-mode (was: ) > HostControllerConnectionService does not let in flight requests clear before stopping > ------------------------------------------------------------------------------------- > > Key: WFCORE-1005 > URL: https://issues.jboss.org/browse/WFCORE-1005 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR4 > Reporter: Brian Stansberry > Labels: domain-mode > > HostControllerConnectionService sets up a remoting channel that receives management requests. But unlike the services that receive end user mgmt requests, it makes no effort to ensure in flight requests have cleared before shutting down. > I haven't looked but I wouldn't be surprised if there's a similar problem with the channel a slave HC opens for communication with the master. > I don't think this is a critical problem; when the service stop ends up closing the channel the remote end will be notified and the in flight request should report a failure. That failure may be unnecessary though. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:44:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:44:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1148) Non runtime-only operation can be invoked in domain servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1148: ------------------------------------- Labels: domain-mode (was: ) > Non runtime-only operation can be invoked in domain servers > ----------------------------------------------------------- > > Key: WFCORE-1148 > URL: https://issues.jboss.org/browse/WFCORE-1148 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.2.Final > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > Priority: Minor > Labels: domain-mode > > While working on WFLY-5418, I noticed that non runtime-only operations can be invoked on domain servers under /host=X/server=Y/... > The operation is not listed in read-operation-names, read-resource-description, etc. but invoking it is still possible. > Brian confirmed that this is a bug and the operation should not be executed. > Steps to reproduce: > * remove the runtimeOnly flag in org.jboss.as.ejb3.subsystem.deployment.MessageDrivenBeanResourceDefinition#registerOperations > * deploy the quickstart helloworld-mdb > * the start-delivery (and stop-delivery) operations are not listed in /host=master/server=server-one/deployment=wildfly-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldQueueMDB:read-operation-names > * But the method can be invoked by executing: > {noformat} > [domain at localhost:9990 /] /host=master/server=server-one/deployment=wildfly-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldQueueMDB:start-delivery ain at localhost:9990 /] > { > "outcome" => "success", > "result" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:45:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1248) Make working directory for server processes configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1248: ------------------------------------- Labels: domain-mode (was: ) > Make working directory for server processes configurable > -------------------------------------------------------- > > Key: WFCORE-1248 > URL: https://issues.jboss.org/browse/WFCORE-1248 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: all > Reporter: Rico Neubauer > Labels: domain-mode > > Currently there is no configuration option to set the working directory of the server-process(es). > Host- and domain-controller both use system-property "user.dir", but for the server-process in org.jboss.as.host.controller.ManagedServer.ProcessAddTask#execute() the following is used to initiate the new process: > > processControllerClient.addProcess(serverProcessName, authKey, command.toArray(new String[command.size()]), environment.getHomeDir().getAbsolutePath(), env); > where environment.getHomeDir().getAbsolutePath() donates the working directory for the new process. > I tested JBoss with changed working directory and this seems not to introduce any issue, so I would request this becomming a configuration option. > A simple approach is to use system-property "user.dir" also for the server-processes. A more advanced soltion is to make this a configuration element/attribute beneath the server-configuration. > See the forum discussion for more references. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:45:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:45:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1220: ------------------------------------- Labels: domain-mode (was: ) > Try closing the channel if java.lang.Error prevents sending error responses to the client > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1220 > URL: https://issues.jboss.org/browse/WFCORE-1220 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: domain-mode > > Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue. > Options: > 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process. > If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process. > 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:47:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:47:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1527) Server group / JVM composite add op and missing parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1527: ------------------------------------- Labels: domain-mode (was: ) > Server group / JVM composite add op and missing parent > ------------------------------------------------------ > > Key: WFCORE-1527 > URL: https://issues.jboss.org/browse/WFCORE-1527 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ken Wills > Assignee: Ken Wills > Labels: domain-mode > > The test AutoIgnoreDomain tests when adding an ignored server group, like this: > https://github.com/luck3y/wildfly-core/blob/6cdd4af55b7723ff943a3743143a6056458f4f56/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/autoignore/AutoIgnoredResourcesDomainTestCase.java#L495 > Also calld the JvmAddHandler. During the JVMH add, the prior add of the server group is not visible in the model and the op fails. > Workaround in JVMAddHandler.populateModel, to attempt to RRFR, and fail silently if the parent is not available, but something prior in the chain is violating the readDomainFromRoot contract, as the server element should be a visible, but uncommitted change in the model. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1667: ------------------------------------- Labels: domain-mode (was: ) > After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1667 > URL: https://issues.jboss.org/browse/WFCORE-1667 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Labels: domain-mode > > When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. > I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78c39d9d994461b0. Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. > Do note that this test may not be needed, but it was an easy way to show what the issue is. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1649: ------------------------------------- Labels: domain-mode (was: ) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 3.0.0.Beta8 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 14:48:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 10 Mar 2017 14:48:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1703) JVM resource handling of jvm-options should detect -D options and integrate with system-property logic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1703: ------------------------------------- Labels: domain-mode (was: ) > JVM resource handling of jvm-options should detect -D options and integrate with system-property logic > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1703 > URL: https://issues.jboss.org/browse/WFCORE-1703 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.2.0.Final > Reporter: Bogdan Ilchyshyn > Priority: Minor > Labels: domain-mode > > It is not possible to set {{jboss.modules.system.pkgs}} property per server / server group in domain configuration. Even when the following configuration is added to {{host.xml}}: > {code:xml} > > > > > > > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:14:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 15 Mar 2017 07:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8371) Undertow https-listener attributes need marking as alternatives to ssl-context attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8371: ----------------------------------- Summary: Undertow https-listener attributes need marking as alternatives to ssl-context attribute. (was: https-listener with ssl-context is not verifying client) > Undertow https-listener attributes need marking as alternatives to ssl-context attribute. > ----------------------------------------------------------------------------------------- > > Key: WFLY-8371 > URL: https://issues.jboss.org/browse/WFLY-8371 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > > https-listener with set ssl-context > {noformat} > > {noformat} > is not verifying client > {noformat} > verify-client="REQUIRED" > {noformat} > Request > {noformat} > curl https://192.168.122.196:8847/ -k > {noformat} > should be rejected, but isn't > {noformat} > $ curl https://192.168.122.196:8847/ -k > > > > JBoss EAP 7 > > > > > > > >
> > >
>
 
>
> 7 >
>
 
>
> > > >
>
>

Welcome to JBoss EAP 7

>

Your Red Hat JBoss Enterprise Application Platform is running.

>

> Administration Console | > Documentation | > Online User Groups
>

> To replace this page simply deploy your own war with / as its context path.
> To disable it, remove the "welcome-content" handler for location / in the undertow subsystem. >
>
> >
> > > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:17:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 15 Mar 2017 07:17:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8371) Undertow https-listener attributes need marking as alternatives to ssl-context attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8371: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Undertow https-listener attributes need marking as alternatives to ssl-context attribute. > ----------------------------------------------------------------------------------------- > > Key: WFLY-8371 > URL: https://issues.jboss.org/browse/WFLY-8371 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > https-listener with set ssl-context > {noformat} > > {noformat} > is not verifying client > {noformat} > verify-client="REQUIRED" > {noformat} > Request > {noformat} > curl https://192.168.122.196:8847/ -k > {noformat} > should be rejected, but isn't > {noformat} > $ curl https://192.168.122.196:8847/ -k > > > > JBoss EAP 7 > > > > > > > >
> > >
>
 
>
> 7 >
>
 
>
> > > >
>
>

Welcome to JBoss EAP 7

>

Your Red Hat JBoss Enterprise Application Platform is running.

>

> Administration Console | > Documentation | > Online User Groups
>

> To replace this page simply deploy your own war with / as its context path.
> To disable it, remove the "welcome-content" handler for location / in the undertow subsystem. >
>
> >
> > > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:17:02 2017 From: issues at jboss.org (Gunnar Morling (JIRA)) Date: Wed, 15 Mar 2017 07:17:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8372) Upgrade to Hibernate Validator 5.3.5 In-Reply-To: References: Message-ID: Gunnar Morling created WFLY-8372: ------------------------------------ Summary: Upgrade to Hibernate Validator 5.3.5 Key: WFLY-8372 URL: https://issues.jboss.org/browse/WFLY-8372 Project: WildFly Issue Type: Component Upgrade Reporter: Gunnar Morling Assignee: Jason Greene For fixing https://issues.jboss.org/browse/JBEAP-9121. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:19:00 2017 From: issues at jboss.org (Gunnar Morling (JIRA)) Date: Wed, 15 Mar 2017 07:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8372) Upgrade to Hibernate Validator 5.3.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gunnar Morling updated WFLY-8372: --------------------------------- Component/s: JPA / Hibernate > Upgrade to Hibernate Validator 5.3.5 > ------------------------------------ > > Key: WFLY-8372 > URL: https://issues.jboss.org/browse/WFLY-8372 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Gunnar Morling > Assignee: Jason Greene > > For fixing https://issues.jboss.org/browse/JBEAP-9121. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:20:00 2017 From: issues at jboss.org (Gunnar Morling (JIRA)) Date: Wed, 15 Mar 2017 07:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8372) Upgrade to Hibernate Validator 5.3.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gunnar Morling reassigned WFLY-8372: ------------------------------------ Assignee: Gunnar Morling (was: Jason Greene) > Upgrade to Hibernate Validator 5.3.5 > ------------------------------------ > > Key: WFLY-8372 > URL: https://issues.jboss.org/browse/WFLY-8372 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Gunnar Morling > Assignee: Gunnar Morling > > For fixing https://issues.jboss.org/browse/JBEAP-9121. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:21:01 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Wed, 15 Mar 2017 07:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2378) Regression against 7.0.GA, Kerberos over CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-2378. -------------------------------- Resolution: Done > Regression against 7.0.GA, Kerberos over CLI > -------------------------------------------- > > Key: WFCORE-2378 > URL: https://issues.jboss.org/browse/WFCORE-2378 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta10 > > > It is not possible to authenticate to CLI using kerberos. > Same configuration works well against 7.0.0.GA > {code:titl=server.log on TRACE level} > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) configuredMaxReceiveBuffer=16777215 > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) relaxComplianceChecks=false > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) QOP={AUTH} > 17:32:21,109 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) Our name 'remote at localhost.localdomain' > 17:32:21,113 INFO [stdout] (management I/O-2) Java config name: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb5-945898887586223869.conf > 17:32:21,113 INFO [stdout] (management I/O-2) Loaded from Java config > 17:32:21,114 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Unable to create SaslServer: javax.security.sasl.SaslException: ELY05029: [GSSAPI] Unable to create GSSContext [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)] > at org.wildfly.security.sasl.gssapi.GssapiServer.(GssapiServer.java:77) > at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44) > at org.wildfly.security.sasl.util.SecurityProviderSaslServerFactory.createSaslServer(SecurityProviderSaslServerFactory.java:77) > at org.wildfly.security.sasl.util.FilterMechanismSaslServerFactory.createSaslServer(FilterMechanismSaslServerFactory.java:88) > at org.wildfly.security.sasl.util.PropertiesSaslServerFactory.createSaslServer(PropertiesSaslServerFactory.java:56) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:79) > at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51) > at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72) > at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) > at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48) > at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51) > at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:59) > at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:50) > at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:259) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:125) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails) > at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:87) > at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:127) > at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193) > at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427) > at sun.security.jgss.GSSCredentialImpl.(GSSCredentialImpl.java:62) > at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154) > at org.wildfly.security.sasl.gssapi.GssapiServer.(GssapiServer.java:72) > ... 24 more > 17:32:21,115 TRACE [org.jboss.remoting.remote] (management I/O-2) Rejected invalid SASL mechanism GSSAPI > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 5 bytes > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:32:21,115 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 59 bytes > 17:32:21,116 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192] > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192] > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1 > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.Beta17-redhat-1" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40" > 17:32:21,116 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service > 17:32:21,116 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 77 bytes > 17:32:21,116 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel > 17:32:21,118 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:32:21,118 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:32:21,118 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF > 17:32:21,118 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream > 17:32:21,441 INFO [org.jboss.eapqe.krbldap.eap7.utils.CustomCLIExecutor] (main) CLI executor output: > 17:32:21,441 INFO [org.jboss.eapqe.krbldap.eap7.utils.CustomCLIExecutor] (main) Java config name: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb5-945898887586223869.conf > Loaded from Java config > >>>KinitOptions cache name is /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb5cc > >>>DEBUG client principal is hnelson7259cb36-69b2-4e28-afb5-f668120a8dea at JBOSS.ORG > >>>DEBUG server principal is krbtgt/JBOSS.ORG at JBOSS.ORG > >>>DEBUG key type: 17 > >>>DEBUG auth time: Thu Feb 23 17:32:11 CET 2017 > >>>DEBUG start time: Thu Feb 23 17:32:11 CET 2017 > >>>DEBUG end time: Fri Feb 24 01:32:11 CET 2017 > >>>DEBUG renew_till time: null > >>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; > Found ticket for hnelson7259cb36-69b2-4e28-afb5-f668120a8dea at JBOSS.ORG to go to krbtgt/JBOSS.ORG at JBOSS.ORG expiring on Fri Feb 24 01:32:11 CET 2017 > Entered Krb5Context.initSecContext with state=STATE_NEW > Service ticket not found in the subject > >>> Credentials acquireServiceCreds: same realm > default etypes for default_tgs_enctypes: 17. > >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KdcAccessibility: reset > >>> KrbKdcReq send: kdc=localhost.localdomain UDP:6088, timeout=5000, number of retries =3, #bytes=648 > >>> KDCCommunication: kdc=localhost.localdomain UDP:6088, timeout=5000,Attempt =1, #bytes=648 > >>> KrbKdcReq send: #bytes read=634 > >>> KdcAccessibility: remove localhost.localdomain:6088 > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000 > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > Krb5Context setting mySeqNumber to: 951540638 > Krb5Context setting peerSeqNumber to: 0 > Created InitSecContextToken: > 0000: 01 00 6E 82 02 2C 30 82 02 28 A0 03 02 01 05 A1 ..n..,0..(...... > 0010: 03 02 01 0E A2 07 03 05 00 00 00 00 00 A3 82 01 ................ > 0020: 2C 61 82 01 28 30 82 01 24 A0 03 02 01 05 A1 0B ,a..(0..$....... > 0030: 1B 09 4A 42 4F 53 53 2E 4F 52 47 A2 2A 30 28 A0 ..JBOSS.ORG.*0(. > 0040: 03 02 01 00 A1 21 30 1F 1B 06 72 65 6D 6F 74 65 .....!0...remote > 0050: 1B 15 6C 6F 63 61 6C 68 6F 73 74 2E 6C 6F 63 61 ..localhost.loca > 0060: 6C 64 6F 6D 61 69 6E A3 81 E3 30 81 E0 A0 03 02 ldomain...0..... > 0070: 01 11 A2 81 D8 04 81 D5 AF 46 53 89 B1 22 66 A6 .........FS.."f. > 0080: C7 3C 9B 50 EB 36 7C D7 95 45 C9 46 BE A7 17 43 .<.P.6...E.F...C > 0090: CD 9E DB B1 34 F7 1E 89 A4 D8 7B 2D 37 F9 4D DE ....4......-7.M. > 00A0: 8C B6 9D 07 83 2B 3E BF 80 34 34 CB 52 B9 01 95 .....+>..44.R... > 00B0: AF 07 D1 8A 15 F8 7D 29 56 03 63 36 13 44 17 0B .......)V.c6.D.. > 00C0: C9 31 CD 6F 41 35 5D B2 5A 5F 25 27 20 8D DE 9A .1.oA5].Z_%' ... > 00D0: 1B A9 26 A9 22 E2 81 4C 18 BB F9 15 27 A4 75 68 ..&."..L....'.uh > 00E0: AF FE F4 2D 84 6D 44 24 73 C8 18 C0 3E 85 3E 0C ...-.mD$s...>.>. > 00F0: 6E 2C 89 FA 54 0B F6 E4 D3 C9 DA A3 61 14 5F 97 n,..T.......a._. > 0100: 1D FE 6A 70 D7 C7 9C D2 91 D7 D0 B0 88 20 A1 C8 ..jp......... .. > 0110: 53 42 DD 6B DB 3C 39 DC 2C DF 8A 52 C9 8B E4 0B SB.k.<9.,..R.... > 0120: AD 05 B8 81 08 0E D2 4E 83 F9 23 C8 DC F1 9A 42 .......N..#....B > 0130: BD 44 A4 DB CB E6 64 9B 9D 53 FA F3 4E 77 99 5F .D....d..S..Nw._ > 0140: AE 0C B3 52 11 B5 6E 65 FB 2C 6E D9 49 A4 81 E2 ...R..ne.,n.I... > 0150: 30 81 DF A0 03 02 01 11 A2 81 D7 04 81 D4 13 3B 0..............; > 0160: BB 37 F0 B9 F9 C3 60 E0 80 DA A2 8D 0C E9 8A 34 .7....`........4 > 0170: DA E1 55 CB 4F 09 EB 36 3A F4 68 D3 90 D9 0F CD ..U.O..6:.h..... > 0180: 0F BA 50 1C A9 5C 70 84 1B CD 43 12 33 41 8A CA ..P..\p...C.3A.. > 0190: 46 B0 21 4B 10 D7 22 5C EC D0 79 C1 0D 5E 1C 58 F.!K.."\..y..^.X > 01A0: 64 7C 75 43 77 96 82 1F 3A AD A2 C1 C4 9B 96 5B d.uCw...:......[ > 01B0: 0D 1B DC 60 BD 76 91 69 53 DE 2F 34 CF 9E 0B EE ...`.v.iS./4.... > 01C0: 8D D9 98 E0 37 AB 8D 2F 0D 61 B5 8C 10 43 20 2B ....7../.a...C + > 01D0: 6D 36 E1 0F 5B 23 22 8A 76 1B 55 0C 2E A1 8C D7 m6..[#".v.U..... > 01E0: 8C 6F D2 07 2B 26 3B BF 54 74 9B 76 4A 78 2B E8 .o..+&;.Tt.vJx+. > 01F0: 70 E3 81 08 E9 8B A3 F1 69 A3 E2 BE 1D 5B 8F 3A p.......i....[.: > 0200: 0F 34 3D 2D 01 69 C4 FC 67 FB 13 4B F3 D9 BE 94 .4=-.i..g..K.... > 0210: 9D 24 75 92 32 13 4B 8B 18 D0 FF 3B F9 51 19 90 .$u.2.K....;.Q.. > 0220: 44 63 61 BF A0 91 9E 76 9D 42 AA 3D B3 46 64 0A Dca....v.B.=.Fd. > 0230: 0D 19 .. > Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9990: Authentication failed: all available authentication mechanisms failed: > GSSAPI: Server rejected authentication > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:39:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 15 Mar 2017 07:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-51) Automation Testcase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan updated HAWKULARQE-51: ------------------------------------- Summary: Automation Testcase (was: Manual Testcases - Create and Run) > Automation Testcase > ------------------- > > Key: HAWKULARQE-51 > URL: https://issues.jboss.org/browse/HAWKULARQE-51 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:42:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 15 Mar 2017 07:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-33) [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan updated HAWKULARQE-33: ------------------------------------- Labels: mm-integration-hawkular-qe (was: ) > [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider > ------------------------------------------------------------- > > Key: HAWKULARQE-33 > URL: https://issues.jboss.org/browse/HAWKULARQE-33 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Vojtech Prusa > Priority: Critical > Labels: mm-integration-hawkular-qe > > See [JMAN4-188|https://issues.jboss.org/browse/JMAN4-188] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:56:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 07:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2535) ModuleResourceRootPathsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated WFCORE-2535: ------------------------------ Summary: ModuleResourceRootPathsTestCase fails with security manager in WF core (was: ModuleResourceRootPathsTestCase fails with security manager) > ModuleResourceRootPathsTestCase fails with security manager in WF core > ---------------------------------------------------------------------- > > Key: WFCORE-2535 > URL: https://issues.jboss.org/browse/WFCORE-2535 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.management.cli.modules.ModuleResourceRootPathsTestCase#testModules* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=ModuleResourceRootPathsTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:26:00,583 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."test-archive.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-archive.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "test-archive.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "jboss.bind.address" "read")" in code source "(vfs:/content/test-archive.war )" of "ModuleClassLoader for Module "deployment.test-archive.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) > at java.lang.System.getProperty(System.java:443) > at java.lang.System.getProperty(System.java:427) > at org.jboss.as.test.shared.TestSuiteEnvironment.getSystemProperty(TestSuiteEnvironment.java:50) > at org.jboss.as.test.shared.TestSuiteEnvironment.getHttpAddress(TestSuiteEnvironment.java:173) > at org.wildfly.test.undertow.UndertowServiceActivator.getAddress(UndertowServiceActivator.java:100) > at org.wildfly.test.undertow.UndertowServiceActivator.activate(UndertowServiceActivator.java:66) > at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 07:59:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 15 Mar 2017 07:59:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8373) Remove the temporary invocation ignores for tests now passing. In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8373: -------------------------------------- Summary: Remove the temporary invocation ignores for tests now passing. Key: WFLY-8373 URL: https://issues.jboss.org/browse/WFLY-8373 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 08:10:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 15 Mar 2017 08:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8374) Configuration differences between default configuration and read/persisted in transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-9594 to WFLY-8374: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8374 (was: JBEAP-9594) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Transactions (was: Transactions) > Configuration differences between default configuration and read/persisted in transactions > ------------------------------------------------------------------------------------------ > > Key: WFLY-8374 > URL: https://issues.jboss.org/browse/WFLY-8374 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > [rhusar at syrah wildfly-11.0.0.Alpha1-SNAPSHOT]$ diff standalone/configuration/standalone-full-ha.xml standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml > snip elytron reported as https://issues.jboss.org/browse/JBEAP-9592 > 557c553 > < > --- > > > 596d591 > < > 611d605 > < -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 08:12:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 15 Mar 2017 08:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8374) Configuration differences between default configuration and read/persisted in transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8374: --------------------------------- Priority: Minor (was: Major) > Configuration differences between default configuration and read/persisted in transactions > ------------------------------------------------------------------------------------------ > > Key: WFLY-8374 > URL: https://issues.jboss.org/browse/WFLY-8374 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > [rhusar at syrah wildfly-11.0.0.Alpha1-SNAPSHOT]$ diff standalone/configuration/standalone-full-ha.xml standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml > snip elytron reported as https://issues.jboss.org/browse/JBEAP-9592 > 557c553 > < > --- > > > 596d591 > < > 611d605 > < -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 08:12:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 15 Mar 2017 08:12:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8374) Configuration differences between default configuration and read/persisted in transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8374: --------------------------------- Affects: User Experience > Configuration differences between default configuration and read/persisted in transactions > ------------------------------------------------------------------------------------------ > > Key: WFLY-8374 > URL: https://issues.jboss.org/browse/WFLY-8374 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > [rhusar at syrah wildfly-11.0.0.Alpha1-SNAPSHOT]$ diff standalone/configuration/standalone-full-ha.xml standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml > snip elytron reported as https://issues.jboss.org/browse/JBEAP-9592 > 557c553 > < > --- > > > 596d591 > < > 611d605 > < -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 08:22:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Wed, 15 Mar 2017 08:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (AG-16) Continous integration In-Reply-To: References: Message-ID: Luis Barreiro created AG-16: ------------------------------- Summary: Continous integration Key: AG-16 URL: https://issues.jboss.org/browse/AG-16 Project: Agroal Issue Type: Task Components: infrastructure Affects Versions: 0.1 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 0.2 Provided by https://travis-ci.org -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 08:34:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 08:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2404) Elytron, unable to create custom principal transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2404: ------------------------------- Git Pull Request: (was: https://github.com/wildfly-security/elytron-subsystem/pull/443) > Elytron, unable to create custom principal transformer > ------------------------------------------------------ > > Key: WFCORE-2404 > URL: https://issues.jboss.org/browse/WFCORE-2404 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > When I try to register custom principal transformer I get {{NoClassDefFoundError}} > {code} > 07:11:37,203 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.mapper.AddCustomPrincipalTransformerImpl in Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 07:11:37,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 07:11:37,207 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-principal-transformer" => "CreaperTestAddCustomPrincipalTransformer") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer" => "org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module \"org.jboss.customprincipaltransformerimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer"] > } > {code} > That works in DR11 without issue > Here is implementation of used custom prncipal transformer > {code:java|title=AddCustomPrincipalTransformerImpl.java} > package org.wildfly.extras.creaper.commands.elytron.mapper; > import org.wildfly.extension.elytron.Configurable; > import java.security.Principal; > import java.util.Map; > import org.wildfly.extension.elytron.capabilities.PrincipalTransformer; > public class AddCustomPrincipalTransformerImpl implements PrincipalTransformer, Configurable { > @Override > public Principal apply(Principal p) { > return p; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 08:46:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Wed, 15 Mar 2017 08:46:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (AG-16) Continous integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AG-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Barreiro resolved AG-16. ----------------------------- Resolution: Done Availabrl at https://travis-ci.org/agroal/agroal > Continous integration > --------------------- > > Key: AG-16 > URL: https://issues.jboss.org/browse/AG-16 > Project: Agroal > Issue Type: Task > Components: infrastructure > Affects Versions: 0.1 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.2 > > > Provided by https://travis-ci.org -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:03:03 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Wed, 15 Mar 2017 09:03:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2500) Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman reassigned WFCORE-2500: ------------------------------------ Assignee: Tomas Hofman (was: Darran Lofthouse) > Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2500 > URL: https://issues.jboss.org/browse/WFCORE-2500 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Tomas Hofman > > Changing attribute changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state even though header allow-resource-service-restart=true is used > {code} > [standalone at localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true} > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Header should work as attribute is declared as {{"restart-required" => "resource-services"}} > {code} > "http-server-mechanism-factory" => { > "type" => STRING, > "description" => "The HttpServerAuthenticationMechanismFactory to associate with this resource", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "capability-reference" => "org.wildfly.security.http-server-mechanism-factory", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > {code} > And according to documentation [1]: > resource-services ? The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.) > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:09:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 15 Mar 2017 09:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8370) Changing global transaction timeout requires reload to be considered for MDB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378384#comment-13378384 ] David Lloyd commented on WFLY-8370: ----------------------------------- It looks fine [~ochaloup]. > Changing global transaction timeout requires reload to be considered for MDB > ---------------------------------------------------------------------------- > > Key: WFLY-8370 > URL: https://issues.jboss.org/browse/WFLY-8370 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondra Chaloupka > Assignee: David Lloyd > > When default transaction timeout is redefined during the server lifetime > {code} > /subsystem=transactions:write-attribute(name=default-timeout, value=60) > {"outcome" => "success"} > {code} > such change is not propagated to WFTC and for example in case of MDB the default transaction timeout is being left as it was at time of container startup. The transaction timeout is considered after server is reloaded. But it's different behavior than it was and in general for transaction timeout redefinition should not be needed container reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:09:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 15 Mar 2017 09:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8370) Changing global transaction timeout requires reload to be considered for MDB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned WFLY-8370: --------------------------------- Assignee: Ondra Chaloupka (was: David Lloyd) > Changing global transaction timeout requires reload to be considered for MDB > ---------------------------------------------------------------------------- > > Key: WFLY-8370 > URL: https://issues.jboss.org/browse/WFLY-8370 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > When default transaction timeout is redefined during the server lifetime > {code} > /subsystem=transactions:write-attribute(name=default-timeout, value=60) > {"outcome" => "success"} > {code} > such change is not propagated to WFTC and for example in case of MDB the default transaction timeout is being left as it was at time of container startup. The transaction timeout is considered after server is reloaded. But it's different behavior than it was and in general for transaction timeout redefinition should not be needed container reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:13:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8375) Some tests fail with security manager due to lack of permission to read EJB client In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8375: ------------------------------- Summary: Some tests fail with security manager due to lack of permission to read EJB client Key: WFLY-8375 URL: https://issues.jboss.org/browse/WFLY-8375 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.jboss.as.test.integration.ejb.injection.ejbref.lookup.EjbRefLookupTestCase#testJBossEjbRefInRest* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=EjbRefLookupTestCase -Dsecurity.manager}} fails with: {code} ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /5e692792-50c7-4f07-8881-e7429386c843/rest/second/text: org.jboss.resteasy.spi.UnhandledException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR13/dist/target/jboss-eap-7.1/modules/system/layers/base/org/jboss/ejb-client/main/jboss-ejb-client-4.0.0.Beta16-redhat-1.jar" "read")" in code source "(vfs:/content/5e692792-50c7-4f07-8881-e7429386c843.war/WEB-INF/classes )" of "null") at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$762.000000004C0FC080.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$763.000000004C1943A0.call(Unknown Source) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) at java.security.AccessController.doPrivileged(AccessController.java:650) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR13/dist/target/jboss-eap-7.1/modules/system/layers/base/org/jboss/ejb-client/main/jboss-ejb-client-4.0.0.Beta16-redhat-1.jar" "read")" in code source "(vfs:/content/5e692792-50c7-4f07-8881-e7429386c843.war/WEB-INF/classes )" of "null") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) at java.lang.SecurityManager.checkRead(SecurityManager.java:901) at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350) at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:158) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:102) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:135) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:163) at java.net.URL.openStream(URL.java:1057) at java.util.ServiceLoader.parse(ServiceLoader.java:315) at java.util.ServiceLoader.access$200(ServiceLoader.java:196) at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:368) at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:334) at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:407) at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:406) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:409) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:485) at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:435) at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:130) at javax.naming.InitialContext.lookup(InitialContext.java:428) at javax.naming.InitialContext.lookup(InitialContext.java:428) at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.doLookup(WeldEjbInjectionServices.java:247) at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices$1.createResource(WeldEjbInjectionServices.java:108) at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:49) at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:63) at org.jboss.weld.util.Beans.injectEEFields(Beans.java:331) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:117) at org.jboss.resteasy.cdi.JaxrsInjectionTarget.inject(JaxrsInjectionTarget.java:44) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100) at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:177) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.jboss.as.test.integration.ejb.injection.ejbref.lookup.SecondRestService$Proxy$_$$_WeldClientProxy.getResultXML(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) ... 50 more {code} Another affected tests found so far: *org.jboss.as.test.integration.ejb.remote.ejbnamespace.EjbNamespaceInvocationTestCase#testDirectLookup* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=EjbNamespaceInvocationTestCase -Dsecurity.manager}} *org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalWithNoDefaultSecurityDomainTestCase#testUnauthenticatedNoSecurityDomain* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=GetCallerPrincipalWithNoDefaultSecurityDomainTestCase -Dsecurity.manager}} *org.jboss.as.test.multinode.transaction.async.TransactionPropagationTestCase#testRemoteInvocation* *org.jboss.as.test.multinode.transaction.async.TransactionPropagationTestCase#testRemoteWithStatusAtRegistry* *org.jboss.as.test.multinode.transaction.async.TransactionPropagationTestCase#testRemoteWithStatusAtTransactionManager* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.multinode -Dtest=TransactionPropagationTestCase -Dsecurity.manager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:18:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8376) ResourceAdapterPoolAttributesTestCase fails with security manager In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8376: ------------------------------- Summary: ResourceAdapterPoolAttributesTestCase fails with security manager Key: WFLY-8376 URL: https://issues.jboss.org/browse/WFLY-8376 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase#testModifyPoolAttributes* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ResourceAdapterPoolAttributesTestCase -Dsecurity.manager}} {code} SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase.testModifyPoolAttributes: java.lang.AssertionError: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/pool-attributes-test.rar/pool-attributes-test.jar )" of "ModuleClassLoader for Module "deployment.pool-attributes-test.rar" from Service Module Loader") at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.jca.JcaTestsUtil.extractConnectionManager(JcaTestsUtil.java:144) at org.jboss.as.test.integration.jca.JcaTestsUtil.exctractPoolConfiguration(JcaTestsUtil.java:89) at org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase.testModifyPoolAttributes(ResourceAdapterPoolAttributesTestCase.java:137) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:24:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8377) ImplementValidityAuditStrategyTestCase fails with security manager In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8377: ------------------------------- Summary: ImplementValidityAuditStrategyTestCase fails with security manager Key: WFLY-8377 URL: https://issues.jboss.org/browse/WFLY-8377 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.jboss.as.test.integration.jpa.hibernate.envers.implementvalidityauditstrategytest.ImplementValidityAuditStrategyTestCase#testValidityStrategyActivationforEnvers* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ImplementValidityAuditStrategyTestCase -Dsecurity.manager}} {code} 14:19:55,505 ERROR [org.hibernate.AssertionFailure] (pool-2-thread-1) HHH000099: an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session): java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/jpa_ImplementValidityAuditStrategyTestCase.jar )" of "ModuleClassLoader for Module "deployment.jpa_ImplementValidityAuditStrategyTestCase.jar" from Service Module Loader") 14:19:55,506 WARN [com.arjuna.ats.arjuna] (pool-2-thread-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a2203d4:6d2c2d66:58c93f6a:15, org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e71e35dd >: org.hibernate.AssertionFailure: Unable to perform beforeTransactionCompletion callback at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:938) at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:507) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2353) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:491) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:316) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:69) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:61) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) at org.jboss.as.test.integration.jpa.hibernate.envers.SLSBValidityStrategyOrg$$$view1.createOrg(Unknown Source) at org.jboss.as.test.integration.jpa.hibernate.envers.implementvalidityauditstrategytest.ImplementValidityAuditStrategyTestCase.testEnversforValidityStrategy(ImplementValidityAuditStrategyTestCase.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/jpa_ImplementValidityAuditStrategyTestCase.jar )" of "ModuleClassLoader for Module "deployment.jpa_ImplementValidityAuditStrategyTestCase.jar" from Service Module Loader") at org.hibernate.envers.internal.revisioninfo.DefaultRevisionInfoGenerator.generate(DefaultRevisionInfoGenerator.java:86) at org.hibernate.envers.internal.synchronization.AuditProcess.getCurrentRevisionData(AuditProcess.java:114) at org.hibernate.envers.internal.synchronization.AuditProcess.executeInSession(AuditProcess.java:96) at org.hibernate.envers.internal.synchronization.AuditProcess.doBeforeTransactionCompletion(AuditProcess.java:153) at org.hibernate.envers.internal.synchronization.AuditProcessManager$1.doBeforeTransactionCompletion(AuditProcessManager.java:46) at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:932) ... 196 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/jpa_ImplementValidityAuditStrategyTestCase.jar )" of "ModuleClassLoader for Module "deployment.jpa_ImplementValidityAuditStrategyTestCase.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.reflect.AccessibleObject.setAccessible(AccessibleObject.java:143) at org.hibernate.internal.util.ReflectHelper.getDefaultConstructor(ReflectHelper.java:262) at org.hibernate.envers.internal.revisioninfo.DefaultRevisionInfoGenerator.generate(DefaultRevisionInfoGenerator.java:83) ... 201 more 14:19:55,512 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-1) WFLYEJB0034: EJB Invocation failed on component SLSBValidityStrategyOrg for method public org.jboss.as.test.integration.jpa.hibernate.envers.Organization org.jboss.as.test.integration.jpa.hibernate.envers.SLSBValidityStrategyOrg.createOrg(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String): javax.ejb.EJBTransactionRolledbackException: Transaction rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) at org.jboss.as.test.integration.jpa.hibernate.envers.SLSBValidityStrategyOrg$$$view1.createOrg(Unknown Source) at org.jboss.as.test.integration.jpa.hibernate.envers.implementvalidityauditstrategytest.ImplementValidityAuditStrategyTestCase.testEnversforValidityStrategy(ImplementValidityAuditStrategyTestCase.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1228) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:69) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:61) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) ... 180 more Caused by: org.hibernate.AssertionFailure: Unable to perform beforeTransactionCompletion callback at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:938) at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:507) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2353) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:491) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:316) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) ... 185 more Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/jpa_ImplementValidityAuditStrategyTestCase.jar )" of "ModuleClassLoader for Module "deployment.jpa_ImplementValidityAuditStrategyTestCase.jar" from Service Module Loader") at org.hibernate.envers.internal.revisioninfo.DefaultRevisionInfoGenerator.generate(DefaultRevisionInfoGenerator.java:86) at org.hibernate.envers.internal.synchronization.AuditProcess.getCurrentRevisionData(AuditProcess.java:114) at org.hibernate.envers.internal.synchronization.AuditProcess.executeInSession(AuditProcess.java:96) at org.hibernate.envers.internal.synchronization.AuditProcess.doBeforeTransactionCompletion(AuditProcess.java:153) at org.hibernate.envers.internal.synchronization.AuditProcessManager$1.doBeforeTransactionCompletion(AuditProcessManager.java:46) at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:932) ... 196 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/jpa_ImplementValidityAuditStrategyTestCase.jar )" of "ModuleClassLoader for Module "deployment.jpa_ImplementValidityAuditStrategyTestCase.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.reflect.AccessibleObject.setAccessible(AccessibleObject.java:143) at org.hibernate.internal.util.ReflectHelper.getDefaultConstructor(ReflectHelper.java:262) at org.hibernate.envers.internal.revisioninfo.DefaultRevisionInfoGenerator.generate(DefaultRevisionInfoGenerator.java:83) ... 201 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:30:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8378) BootstrapBeanDeploymentArchiveTestCase fails with security manager In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8378: ------------------------------- Summary: BootstrapBeanDeploymentArchiveTestCase fails with security manager Key: WFLY-8378 URL: https://issues.jboss.org/browse/WFLY-8378 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.wildfly.test.integration.weld.beanarchives.BootstrapBeanDeploymentArchiveTestCase* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=BootstrapBeanDeploymentArchiveTestCase -Dsecurity.manager}} {code} ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."17004ed3-67af-464b-832a-56e1a1fe7f3d.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."17004ed3-67af-464b-832a-56e1a1fe7f3d.war".WeldStartService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: Exception 0 : javax.enterprise.event.ObserverException at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1899) at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) at java.security.AccessController.doPrivileged(AccessController.java:650) at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:96) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:62) at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:431) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) Caused by: java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.ensureError(J9VMInternals.java:141) at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:130) at org.wildfly.test.integration.weld.beanarchives.TestExtension.beforeBeanDiscovery(TestExtension.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) ... 21 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/17004ed3-67af-464b-832a-56e1a1fe7f3d.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.17004ed3-67af-464b-832a-56e1a1fe7f3d.war" 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.Class.checkMemberAccess(Class.java:200) at java.lang.Class.getDeclaredMethods(Class.java:992) at javax.enterprise.util.AnnotationLiteral.getMembers(AnnotationLiteral.java:78) at javax.enterprise.util.AnnotationLiteral.(AnnotationLiteral.java:69) at org.wildfly.test.integration.weld.beanarchives.Alpha$Literal.(Alpha.java:39) at org.wildfly.test.integration.weld.beanarchives.Alpha$Literal.(Alpha.java:42) ... 27 more at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46) at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:62) at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:431) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) ... 3 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:31:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Wed, 15 Mar 2017 09:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1477) DMN Extension Elements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli reassigned DROOLS-1477: ------------------------------------- Assignee: Alexandros Koufoudakis (was: Edson Tirelli) > DMN Extension Elements > ---------------------- > > Key: DROOLS-1477 > URL: https://issues.jboss.org/browse/DROOLS-1477 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Alexandros Koufoudakis > Assignee: Alexandros Koufoudakis > > Currently, the extension elements are disregarded. As I'm working in one of the projects, which uses Drools 7 beta release and relies on extension elements, I would like to add this feature and to try to implement it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:36:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8379) TransactionScopedJMSContextTestCase fails with security manager In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8379: ------------------------------- Summary: TransactionScopedJMSContextTestCase fails with security manager Key: WFLY-8379 URL: https://issues.jboss.org/browse/WFLY-8379 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.jboss.as.test.integration.messaging.jms.context.transactionscoped.TransactionScopedJMSContextTestCase#sendAndReceiveWithContext* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=TransactionScopedJMSContextTestCase -Dsecurity.manager}} {code} 14:33:57,124 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-5) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar )" of "null") 14:33:57,124 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-4) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar )" of "null") 14:33:57,125 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-2) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar )" of "null") 14:33:57,125 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar )" of "null") 14:33:57,126 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-3) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar )" of "null") 14:34:28,356 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.integration.messaging.jms.context.transactionscoped.TransactionScopedJMSContextTestCase.sendAndReceiveWithContext: java.lang.AssertionError: expected:<50> but was:<0> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.jboss.as.test.integration.messaging.jms.context.transactionscoped.TransactionScopedJMSContextTestCase.sendAndReceiveWithContext(TransactionScopedJMSContextTestCase.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:42:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8380) Xerces usage tests fail with security manager In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8380: ------------------------------- Summary: Xerces usage tests fail with security manager Key: WFLY-8380 URL: https://issues.jboss.org/browse/WFLY-8380 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase#org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}} *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}} {code} 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:346) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) at org.jboss.modules.Module.loadModuleClass(Module.java:708) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) at org.jboss.threads.JBossThread.run(JBossThread.java:320) 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader") at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:346) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) at org.jboss.modules.Module.loadModuleClass(Module.java:708) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) ... 25 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:46:02 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 09:46:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8381) EjbInWarLibPackagingTestCase fails with security manager In-Reply-To: References: Message-ID: Jan Tymel created WFLY-8381: ------------------------------- Summary: EjbInWarLibPackagingTestCase fails with security manager Key: WFLY-8381 URL: https://issues.jboss.org/browse/WFLY-8381 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Jan Tymel *org.jboss.as.test.integration.weld.ejb.packaging.warlib.EjbInWarLibPackagingTestCase#testEjbInWarLibResolvedCorrectly* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=EjbInWarLibPackagingTestCase -Dsecurity.manager}} {code} 14:44:19,372 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-1) WFLYEJB0034: EJB Invocation failed on component WarLibEjb for method public abstract org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb org.jboss.as.test.integration.weld.ejb.packaging.warlib.WarLibInterface.getEjb(): javax.ejb.EJBException: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) at org.jboss.as.test.integration.weld.ejb.packaging.warlib.WarLibInterface$$$view2.getEjb(Unknown Source) at org.jboss.as.test.integration.weld.ejb.packaging.warlib.EjbInWarLibPackagingTestCase.testEjbInWarLibResolvedCorrectly(EjbInWarLibPackagingTestCase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:64) at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:61) at org.jboss.as.ejb3.pool.AbstractPool.create(AbstractPool.java:56) at org.jboss.as.ejb3.pool.strictmax.StrictMaxPool.get(StrictMaxPool.java:124) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 179 more Caused by: javax.ejb.EJBException: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb with qualifiers [@Any @Default]; local interfaces are [OtherEjb] Proxy: class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb$Proxy$_$$_Weld$EnterpriseProxy$ at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:344) at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) ... 188 more Caused by: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb with qualifiers [@Any @Default]; local interfaces are [OtherEjb] Proxy: class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb$Proxy$_$$_Weld$EnterpriseProxy$ at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:72) at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:758) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:858) at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:150) at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:75) at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112) at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180) at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.produce(SessionBeanInjectionTarget.java:126) at org.jboss.as.weld.injection.WeldInjectionContext.produce(WeldInjectionContext.java:46) at org.jboss.as.weld.injection.WeldConstructionStartInterceptor.processInvocation(WeldConstructionStartInterceptor.java:37) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:26) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 201 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/CdiInterceptorPackaging.war/WEB-INF/lib/lib.jar )" of "ModuleClassLoader for Module "deployment.CdiInterceptorPackaging.war" 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.Class.checkMemberAccess(Class.java:200) at java.lang.Class.getDeclaredConstructors(Class.java:719) at org.jboss.weld.util.reflection.DeclaredMemberIndexer.getDeclaredConstructors(DeclaredMemberIndexer.java:146) at org.jboss.weld.util.reflection.DeclaredMemberIndexer.getIndexForConstructor(DeclaredMemberIndexer.java:93) at org.jboss.weld.serialization.ConstructorHolder.(ConstructorHolder.java:46) at org.jboss.weld.serialization.ConstructorHolder.of(ConstructorHolder.java:37) at org.jboss.weld.serialization.InjectionPointHolder$ConstructorParameterInjectionPointIdentifier.(InjectionPointHolder.java:220) at org.jboss.weld.serialization.InjectionPointHolder.(InjectionPointHolder.java:65) at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:51) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:78) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) ... 227 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 09:53:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 15 Mar 2017 09:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2538) DeploymentOperationsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2538: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Tomaz Cerar) > DeploymentOperationsTestCase fails with security manager in WF core > ------------------------------------------------------------------- > > Key: WFCORE-2538 > URL: https://issues.jboss.org/browse/WFCORE-2538 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testBrowseContentFailsNonexistentPath* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedOperationsFailWithUnmanagedArchiveDeployment* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedOperationsFailWithUnmanagedExplodedDeployment* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testReadContentFailsDirectory* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testReadContentFailsNonExistentPath* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testAddContentFailsWithoutOverwriteManagedExplodedDeployment* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testExplodeFailsWithDeployedManagedArchiveDeployment* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedAttributeReadOnly* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedAttributeValue* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedExplodedOperationsFailWithManagedArchiveDeployment* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedExplodedOperationsFailWithUnmanagedArchiveDeployment* > *org.wildfly.core.test.standalone.mgmt.api.core.DeploymentOperationsTestCase#testManagedExplodedOperationsFailWithUnmanagedExplodedDeployment* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=DeploymentOperationsTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service test.deployment.trivial: org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test-deployment.jarService" "write")" in code source "(vfs:/home/jtymel/jboss-eap/src/7.1/jboss-eap-7.1.0.DR13-core/testsuite/standalone/target/archives/test-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-deployment.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:476) > 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) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:06:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Wed, 15 Mar 2017 10:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1475) Item definition without allowed values and is collection set is ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli resolved DROOLS-1475. ----------------------------------- Resolution: Done > Item definition without allowed values and is collection set is ignored > ----------------------------------------------------------------------- > > Key: DROOLS-1475 > URL: https://issues.jboss.org/browse/DROOLS-1475 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > Simple type definitions without `allowed values` or `is collection` property set is ignored. > E.g.: > {code:xml} > > feel:number > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:09:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 15 Mar 2017 10:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8380) Xerces usage tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated WFLY-8380: ---------------------------- Description: *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}} *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}} {code} 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:346) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) at org.jboss.modules.Module.loadModuleClass(Module.java:708) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) at org.jboss.threads.JBossThread.run(JBossThread.java:320) 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader") at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:346) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) at org.jboss.modules.Module.loadModuleClass(Module.java:708) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) ... 25 more {code} was: *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase#org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}} *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService* {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}} {code} 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:346) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) at org.jboss.modules.Module.loadModuleClass(Module.java:708) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) at org.jboss.threads.JBossThread.run(JBossThread.java:320) 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader") at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:785) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) at java.security.AccessController.doPrivileged(AccessController.java:620) at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:346) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) at org.jboss.modules.Module.loadModuleClass(Module.java:708) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) ... 25 more {code} > Xerces usage tests fail with security manager > --------------------------------------------- > > Key: WFLY-8380 > URL: https://issues.jboss.org/browse/WFLY-8380 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}} > *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}} > {code} > 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) > at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) > at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) > at java.security.AccessController.doPrivileged(AccessController.java:620) > at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:346) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) > at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader") > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) > at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) > at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) > at java.security.AccessController.doPrivileged(AccessController.java:620) > at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:346) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) > at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:23:01 2017 From: issues at jboss.org (Guillaume Smet (JIRA)) Date: Wed, 15 Mar 2017 10:23:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8372) Upgrade to Hibernate Validator 5.3.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378487#comment-13378487 ] Guillaume Smet edited comment on WFLY-8372 at 3/15/17 10:22 AM: ---------------------------------------------------------------- PR is here: https://github.com/wildfly/wildfly/pull/9811 As for the changes (see https://hibernate.atlassian.net/projects/HV/versions/26402/tab/release-report-all-issues ): *Bugfixes* * HV-1280 Class loading conflict when custom Xerces is part of a deployment <- this is the issue reported in https://issues.jboss.org/browse/JBEAP-9121 * HV-1220 Programmatically defined cross parameter method constraints don't work on method returning void <- simple bugfix of something not working correctly at all * HV-1284 Reenable testing under the security manager <- this is a build issue, no consequences at runtime *Java 9 compatibility improvements* * HV-1187 Support JDK9 ea+148 * HV-1266 Update build instructions as per latest Java 9 releases * HV-1210 Upgrade to Groovy 2.4.8 was (Author: guillaume.smet): PR is here: https://github.com/wildfly/wildfly/pull/9811 As for the changes (see https://hibernate.atlassian.net/projects/HV/versions/26402/tab/release-report-all-issues): *Bugfixes* * HV-1280 Class loading conflict when custom Xerces is part of a deployment <- this is the issue reported in https://issues.jboss.org/browse/JBEAP-9121 * HV-1220 Programmatically defined cross parameter method constraints don't work on method returning void <- simple bugfix of something not working correctly at all * HV-1284 Reenable testing under the security manager <- this is a build issue, no consequences at runtime *Java 9 compatibility improvements* * HV-1187 Support JDK9 ea+148 * HV-1266 Update build instructions as per latest Java 9 releases * HV-1210 Upgrade to Groovy 2.4.8 > Upgrade to Hibernate Validator 5.3.5 > ------------------------------------ > > Key: WFLY-8372 > URL: https://issues.jboss.org/browse/WFLY-8372 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Gunnar Morling > Assignee: Gunnar Morling > > For fixing https://issues.jboss.org/browse/JBEAP-9121. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:23:01 2017 From: issues at jboss.org (Guillaume Smet (JIRA)) Date: Wed, 15 Mar 2017 10:23:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8372) Upgrade to Hibernate Validator 5.3.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378487#comment-13378487 ] Guillaume Smet commented on WFLY-8372: -------------------------------------- PR is here: https://github.com/wildfly/wildfly/pull/9811 As for the changes (see https://hibernate.atlassian.net/projects/HV/versions/26402/tab/release-report-all-issues): *Bugfixes* * HV-1280 Class loading conflict when custom Xerces is part of a deployment <- this is the issue reported in https://issues.jboss.org/browse/JBEAP-9121 * HV-1220 Programmatically defined cross parameter method constraints don't work on method returning void <- simple bugfix of something not working correctly at all * HV-1284 Reenable testing under the security manager <- this is a build issue, no consequences at runtime *Java 9 compatibility improvements* * HV-1187 Support JDK9 ea+148 * HV-1266 Update build instructions as per latest Java 9 releases * HV-1210 Upgrade to Groovy 2.4.8 > Upgrade to Hibernate Validator 5.3.5 > ------------------------------------ > > Key: WFLY-8372 > URL: https://issues.jboss.org/browse/WFLY-8372 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Gunnar Morling > Assignee: Gunnar Morling > > For fixing https://issues.jboss.org/browse/JBEAP-9121. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:37:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 15 Mar 2017 10:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2542) Upgrade wildfly-discovery to 1.0.0.Beta10 In-Reply-To: References: Message-ID: Farah Juma created WFCORE-2542: ---------------------------------- Summary: Upgrade wildfly-discovery to 1.0.0.Beta10 Key: WFCORE-2542 URL: https://issues.jboss.org/browse/WFCORE-2542 Project: WildFly Core Issue Type: Component Upgrade Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:41:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 15 Mar 2017 10:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2152) HttpManagementResourceDefinition attributes definitions are wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378503#comment-13378503 ] Brian Stansberry commented on WFCORE-2152: ------------------------------------------ https://github.com/wildfly/wildfly-core/pull/2217 has a fix for WFCORE-2152 but referencing WFCORE-2344 and WFCORE-2345 > HttpManagementResourceDefinition attributes definitions are wrong > ----------------------------------------------------------------- > > Key: WFCORE-2152 > URL: https://issues.jboss.org/browse/WFCORE-2152 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > The attributesd are using a reload required write handler while using OperationEntry.Flag.RESTART_RESOURCE_SERVICES in their definition -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 10:41:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 15 Mar 2017 10:41:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2152) HttpManagementResourceDefinition attributes definitions are wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-2152. -------------------------------------- Resolution: Duplicate Issue > HttpManagementResourceDefinition attributes definitions are wrong > ----------------------------------------------------------------- > > Key: WFCORE-2152 > URL: https://issues.jboss.org/browse/WFCORE-2152 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > The attributesd are using a reload required write handler while using OperationEntry.Flag.RESTART_RESOURCE_SERVICES in their definition -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:02:01 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 15 Mar 2017 11:02:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378533#comment-13378533 ] James Perkins commented on WFCORE-482: -------------------------------------- I've actually got a project that will actually write log4j2 messages to the logging subsystem, https://github.com/jamezp/log4j2-jboss-logmanager. A new project could be created and added to WildFly without too much of a problem. The problem is I don't really know what users expect. If they include a log4j2 configuration file, then that will not be used. Things like async-loggers won't be used either. I suppose the easiest approach is to just make the log4j2-jboss-logmanager an official project so logs are written via the logging subsystem. If users expect log4j2 to work with their own configuration they're going to have to exclude the dependencies provided by the server and handle it that way. > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.jboss.org/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Optional > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:03:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 15 Mar 2017 11:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-55) CFME Tests: Adjust environment and smoke tests to JMAN4-111 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan resolved HAWKULARQE-55. -------------------------------------- Resolution: Done PR merged with failure tests fix. Environment is created. > CFME Tests: Adjust environment and smoke tests to JMAN4-111 > ----------------------------------------------------------- > > Key: HAWKULARQE-55 > URL: https://issues.jboss.org/browse/HAWKULARQE-55 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > > Once [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] feature is done, EAP servers on Containers will become immutable, but our CFME Testing environment runs on Containers. > * switch EAP7 Containers to VMs > * and for container EAP7 make smoke tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:07:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 11:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8382) Elytron, unable to create custom principal transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina moved WFCORE-2404 to WFLY-8382: ------------------------------------------ Project: WildFly (was: WildFly Core) Key: WFLY-8382 (was: WFCORE-2404) Component/s: Security (was: Security) > Elytron, unable to create custom principal transformer > ------------------------------------------------------ > > Key: WFLY-8382 > URL: https://issues.jboss.org/browse/WFLY-8382 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > When I try to register custom principal transformer I get {{NoClassDefFoundError}} > {code} > 07:11:37,203 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.mapper.AddCustomPrincipalTransformerImpl in Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 07:11:37,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 07:11:37,207 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-principal-transformer" => "CreaperTestAddCustomPrincipalTransformer") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer" => "org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module \"org.jboss.customprincipaltransformerimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer"] > } > {code} > That works in DR11 without issue > Here is implementation of used custom prncipal transformer > {code:java|title=AddCustomPrincipalTransformerImpl.java} > package org.wildfly.extras.creaper.commands.elytron.mapper; > import org.wildfly.extension.elytron.Configurable; > import java.security.Principal; > import java.util.Map; > import org.wildfly.extension.elytron.capabilities.PrincipalTransformer; > public class AddCustomPrincipalTransformerImpl implements PrincipalTransformer, Configurable { > @Override > public Principal apply(Principal p) { > return p; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:09:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 15 Mar 2017 11:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: Geoffrey De Smet created DROOLS-1478: ---------------------------------------- Summary: Call ActivationUnMatchListener also when a rule rematches Key: DROOLS-1478 URL: https://issues.jboss.org/browse/DROOLS-1478 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Geoffrey De Smet Assignee: Mario Fusco ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (that doesn't work for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // should be 6! w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // should be 0! {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:09:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 15 Mar 2017 11:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1478: ------------------------------------- Description: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // should be 6! w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // should be 0! {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} was: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (that doesn't work for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // should be 6! w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // should be 0! {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} > Call ActivationUnMatchListener also when a rule rematches > --------------------------------------------------------- > > Key: DROOLS-1478 > URL: https://issues.jboss.org/browse/DROOLS-1478 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > ActivationUnMatchListener is part of kie-internal, so its *not public API*. > *ActivationUnMatchListener is only used by OptaPlanner* (probably): > jBPM and downstream drools module don't use it: > https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code > Community users probably don't use it either, because no one mentions it on StackOverflow: > https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* > The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). > For example, given this rule > {code} > global int score = 0; > rule R > when > Wine(age < 10, $age : age) > then > score += $age; > addUnmatchListener(() -> score -= $age); > end > {code} > This works for a normal match and unmatch event: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 0; // GOOD > {code} > So events are like this: > {code} > RHS > unmatch > {code} > However if we have a rematch: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 4; > update(w); > fireAllRules(); => no unmatch triggers => score = 13; // should be 6! > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 7; // should be 0! > {code} > Because the events are unbalanced: > {code} > RHS > RHS > unmatch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:10:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 15 Mar 2017 11:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1478: ------------------------------------- Description: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD should be 6! w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // should be 0! {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} was: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // should be 6! w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // should be 0! {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} > Call ActivationUnMatchListener also when a rule rematches > --------------------------------------------------------- > > Key: DROOLS-1478 > URL: https://issues.jboss.org/browse/DROOLS-1478 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > ActivationUnMatchListener is part of kie-internal, so its *not public API*. > *ActivationUnMatchListener is only used by OptaPlanner* (probably): > jBPM and downstream drools module don't use it: > https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code > Community users probably don't use it either, because no one mentions it on StackOverflow: > https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* > The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). > For example, given this rule > {code} > global int score = 0; > rule R > when > Wine(age < 10, $age : age) > then > score += $age; > addUnmatchListener(() -> score -= $age); > end > {code} > This works for a normal match and unmatch event: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 0; // GOOD > {code} > So events are like this: > {code} > RHS > unmatch > {code} > However if we have a rematch: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 4; > update(w); > fireAllRules(); => no unmatch triggers => score = 13; // BAD should be 6! > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 7; // should be 0! > {code} > Because the events are unbalanced: > {code} > RHS > RHS > unmatch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:10:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 15 Mar 2017 11:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1478: ------------------------------------- Description: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // Should be 0. {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} was: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD should be 6! w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // should be 0! {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} > Call ActivationUnMatchListener also when a rule rematches > --------------------------------------------------------- > > Key: DROOLS-1478 > URL: https://issues.jboss.org/browse/DROOLS-1478 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > ActivationUnMatchListener is part of kie-internal, so its *not public API*. > *ActivationUnMatchListener is only used by OptaPlanner* (probably): > jBPM and downstream drools module don't use it: > https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code > Community users probably don't use it either, because no one mentions it on StackOverflow: > https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* > The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). > For example, given this rule > {code} > global int score = 0; > rule R > when > Wine(age < 10, $age : age) > then > score += $age; > addUnmatchListener(() -> score -= $age); > end > {code} > This works for a normal match and unmatch event: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 0; // GOOD > {code} > So events are like this: > {code} > RHS > unmatch > {code} > However if we have a rematch: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 4; > update(w); > fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 7; // Should be 0. > {code} > Because the events are unbalanced: > {code} > RHS > RHS > unmatch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:12:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 15 Mar 2017 11:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1478: ------------------------------------- Description: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* ---- The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // Should be 0. {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} was: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // Should be 0. {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} > Call ActivationUnMatchListener also when a rule rematches > --------------------------------------------------------- > > Key: DROOLS-1478 > URL: https://issues.jboss.org/browse/DROOLS-1478 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > ActivationUnMatchListener is part of kie-internal, so its *not public API*. > *ActivationUnMatchListener is only used by OptaPlanner* (probably): > jBPM and downstream drools module don't use it: > https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code > Community users probably don't use it either, because no one mentions it on StackOverflow: > https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* > ---- > The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). > For example, given this rule > {code} > global int score = 0; > rule R > when > Wine(age < 10, $age : age) > then > score += $age; > addUnmatchListener(() -> score -= $age); > end > {code} > This works for a normal match and unmatch event: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 0; // GOOD > {code} > So events are like this: > {code} > RHS > unmatch > {code} > However if we have a rematch: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 4; > update(w); > fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 7; // Should be 0. > {code} > Because the events are unbalanced: > {code} > RHS > RHS > unmatch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:14:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 15 Mar 2017 11:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-1478: ------------------------------------- Description: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* ---- The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // Should be 0. {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} I'd argue that anyone using the ActivationUnMatchListener would want to the have balanced events. was: ActivationUnMatchListener is part of kie-internal, so its *not public API*. *ActivationUnMatchListener is only used by OptaPlanner* (probably): jBPM and downstream drools module don't use it: https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code Community users probably don't use it either, because no one mentions it on StackOverflow: https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* ---- The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). For example, given this rule {code} global int score = 0; rule R when Wine(age < 10, $age : age) then score += $age; addUnmatchListener(() -> score -= $age); end {code} This works for a normal match and unmatch event: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 0; // GOOD {code} So events are like this: {code} RHS unmatch {code} However if we have a rematch: {code} Wine w = new Wine(3); insert(w); fireAllRules(); => score = 7; w.age = 4; update(w); fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. w.age = 50; update(w); fireAllRules(); => unmatch triggers => score = 7; // Should be 0. {code} Because the events are unbalanced: {code} RHS RHS unmatch {code} > Call ActivationUnMatchListener also when a rule rematches > --------------------------------------------------------- > > Key: DROOLS-1478 > URL: https://issues.jboss.org/browse/DROOLS-1478 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > ActivationUnMatchListener is part of kie-internal, so its *not public API*. > *ActivationUnMatchListener is only used by OptaPlanner* (probably): > jBPM and downstream drools module don't use it: > https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code > Community users probably don't use it either, because no one mentions it on StackOverflow: > https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* > ---- > The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). > For example, given this rule > {code} > global int score = 0; > rule R > when > Wine(age < 10, $age : age) > then > score += $age; > addUnmatchListener(() -> score -= $age); > end > {code} > This works for a normal match and unmatch event: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 0; // GOOD > {code} > So events are like this: > {code} > RHS > unmatch > {code} > However if we have a rematch: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 4; > update(w); > fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 7; // Should be 0. > {code} > Because the events are unbalanced: > {code} > RHS > RHS > unmatch > {code} > I'd argue that anyone using the ActivationUnMatchListener would want to the have balanced events. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:21:00 2017 From: issues at jboss.org (David Mulford (JIRA)) Date: Wed, 15 Mar 2017 11:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8383) The current JBoss EAP version is not load balancing websocket requests when using Undertow as a load balancer when mod_cluster is used. This causes all websocket sessions to be created at a single backend server. In-Reply-To: References: Message-ID: David Mulford created WFLY-8383: ----------------------------------- Summary: The current JBoss EAP version is not load balancing websocket requests when using Undertow as a load balancer when mod_cluster is used. This causes all websocket sessions to be created at a single backend server. Key: WFLY-8383 URL: https://issues.jboss.org/browse/WFLY-8383 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Reporter: David Mulford Assignee: Stuart Douglas User is looking for functionality similar to that of mod_proxy_wstunnel for Apache httpd, and wants this in Undertow's mod_cluster implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:22:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 15 Mar 2017 11:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1479) Allow serialization of a session using the parallel engine In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1479: ----------------------------------- Summary: Allow serialization of a session using the parallel engine Key: DROOLS-1479 URL: https://issues.jboss.org/browse/DROOLS-1479 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 11:47:00 2017 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Wed, 15 Mar 2017 11:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8384) java.lang.ClassNotFoundException: org.wildfly.transaction.client.LocalTransactionContext from Module "org.jboss.as.webservices" In-Reply-To: References: Message-ID: Alessio Soldano created WFLY-8384: ------------------------------------- Summary: java.lang.ClassNotFoundException: org.wildfly.transaction.client.LocalTransactionContext from Module "org.jboss.as.webservices" Key: WFLY-8384 URL: https://issues.jboss.org/browse/WFLY-8384 Project: WildFly Issue Type: Task Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Priority: Blocker Fix For: 11.0.0.Alpha1 {noformat}java.lang.ClassNotFoundException: org.wildfly.transaction.client.LocalTransactionContext from [Module "org.jboss.as.webservices" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /data/workspace/jbossws-hudson-5.2.0-SNAPSHOT/hudson-home/jobs/CXF-CORE-AS-11.0.0/workspace/jboss-as/modules,/data/workspace/jbossws-hudson-5.2.0-SNAPSHOT/hudson-home/jobs/CXF-CORE-AS-11.0.0/workspace/jboss-as/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) ... 65 more {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 12:04:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Wed, 15 Mar 2017 12:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8021) JMS-Bridge ignore source-credential-reference attribute In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil reassigned WFLY-8021: --------------------------------- Assignee: Jeff Mesnil (was: Peter Skopek) > JMS-Bridge ignore source-credential-reference attribute > ------------------------------------------------------- > > Key: WFLY-8021 > URL: https://issues.jboss.org/browse/WFLY-8021 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Jeff Mesnil > > I catch issue with JMS-Bridge integration with Credential store through credential-reference attribute. > There is problem with source-credential-reference (target-credential-reference works fine). > Problem is that source-credential-reference is ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 12:04:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 12:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-977) PLAIN mechanism does not work with WildFlyElytronProvider for AuthenticationConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378599#comment-13378599 ] Jan Kalina commented on ELY-977: -------------------------------- Adding *configurable-sasl-server-factory* necessary, or individual mechanism exceeds 8 allowed authentication attemps: {code:xml} {code} Only considerable improvement could be automatic filtering in *sasl-authentication-factory* by configured mechanisms - but mechanism name is optional here, so it would work only when it would be specified for all . > PLAIN mechanism does not work with WildFlyElytronProvider for AuthenticationConfiguration > ----------------------------------------------------------------------------------------- > > Key: ELY-977 > URL: https://issues.jboss.org/browse/ELY-977 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta25 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when WildFlyElytronProvider is set as provider for AuthenticationConfiguration then SASL PLAIN mechanism is stopped to work (see exception below). In case when WildFlyElytronProvider is removed then PLAIN mechanism works. It seems that Elytron does not implement SASL PLAIN mechanism correctly. > Thrown Exception: > {code} > java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.wildfly.security.elytron.SimpleClient$1.run(SimpleClient.java:67) > at org.wildfly.common.context.Contextual.run(Contextual.java:71) > at org.wildfly.security.elytron.SimpleClient.main(SimpleClient.java:48) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > ... 10 more > Caused by: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 6900a112 to /127.0.0.1:9990 of endpoint "management-client" <7c9695fa> > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:578) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:546) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:464) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:426) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:414) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:164) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:111) > ... 20 more > {code} > We request blocker flag because this issue blocks RFE EAP7-530. PLAIN is widely used SASL mechanism. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 12:06:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 12:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2380) JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378600#comment-13378600 ] Jan Kalina commented on WFCORE-2380: ------------------------------------ Adding configurable-sasl-server-factory necessary, or individual mechanism exceeds 8 allowed authentication attemps: {code:xml} {code} Only considerable improvement could be automatic filtering in sasl-authentication-factory by configured mechanisms - but mechanism name is optional here, so it would work only when it would be specified for all . > JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-2380 > URL: https://issues.jboss.org/browse/WFCORE-2380 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when PLAIN mechanism is used for Elytron SASL factories used by any of management-interfaces then JBoss CLI is not able to connect to the server. This issue happens with http-interface as well as native-interface. See Steps to Reproduce for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 12:38:00 2017 From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=) Date: Wed, 15 Mar 2017 12:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8385) Upgrade Hibernate Validator from 5.3.4.Final to 5.3.5.Final In-Reply-To: References: Message-ID: Bartosz Spyrko-?mietanko created WFLY-8385: ---------------------------------------------- Summary: Upgrade Hibernate Validator from 5.3.4.Final to 5.3.5.Final Key: WFLY-8385 URL: https://issues.jboss.org/browse/WFLY-8385 Project: WildFly Issue Type: Component Upgrade Reporter: Bartosz Spyrko-?mietanko Assignee: Bartosz Spyrko-?mietanko -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 12:40:00 2017 From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=) Date: Wed, 15 Mar 2017 12:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8386) [7.1.x] Upgrade Hibernate Validator from 5.3.4.Final to 5.3.5.Final In-Reply-To: References: Message-ID: Bartosz Spyrko-?mietanko created WFLY-8386: ---------------------------------------------- Summary: [7.1.x] Upgrade Hibernate Validator from 5.3.4.Final to 5.3.5.Final Key: WFLY-8386 URL: https://issues.jboss.org/browse/WFLY-8386 Project: WildFly Issue Type: Component Upgrade Reporter: Bartosz Spyrko-?mietanko Assignee: Bartosz Spyrko-?mietanko -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:08:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Wed, 15 Mar 2017 13:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-64) [QE] - JMAN4-126 - Enable and Disable deployments in an Server Group In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378648#comment-13378648 ] Matt Mahoney commented on HAWKULARQE-64: ---------------------------------------- Development confirmed that JMAN4-126 will not 4.5. Task has been moved from In Progress back to Open. > [QE] - JMAN4-126 - Enable and Disable deployments in an Server Group > -------------------------------------------------------------------- > > Key: HAWKULARQE-64 > URL: https://issues.jboss.org/browse/HAWKULARQE-64 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: mfoley user > > See [JMAN4-126|https://issues.jboss.org/browse/JMAN4-126] > Dev task for it [HAWKULAR-1165|https://issues.jboss.org/browse/HAWKULAR-1165] > This is 5.0 release planed feature, but is in development of 4.5. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:09:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 13:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2392: ------------------------------- Steps to Reproduce: Checkout wildfly ladybird and run test: {code} cd testsuite/elytron mvn clean test -Dtest=org.wildfly.test.integration.elytron.ejb.AuthenticationTestCase {code} (need to un-ignore tests tagged as [WFLY-7778]) was: Tests: (after modification to use Elytron instead of legacy subystem: https://github.com/wildfly-security-incubator/wildfly/pull/56 ) org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.testAuthentication() org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.testAuthentication_BadPwd() org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.testAuthentication_TwoBeans() org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_BadPwd() (and a lot of other, most of tests using EJB) UPDATE: https://github.com/wildfly-security-incubator/wildfly/pull/102 instead and following with -Delytron option: org.jboss.as.test.integration.ejb.security.AuthenticationElytronTestCase.testAuthentication() > Remoting EJB identity propagation does not work with Elytron > ------------------------------------------------------------ > > Key: WFCORE-2392 > URL: https://issues.jboss.org/browse/WFCORE-2392 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron-legacy-test-fails > > Even througth succesful obtaining LoginContext, identity is not propagated in EJB call. > Identity is unauthorized on server side. > *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference. > Often error message: > {code:java} > SaslException: Authentication failed: all available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:10:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 13:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2392: ------------------------------- Steps to Reproduce: Checkout wildfly ladybird and run test: {code} cd testsuite/elytron mvn clean test -Dtest=org.wildfly.test.integration.elytron.ejb.AuthenticationTestCase {code} (need to unignore tests tagged as [WFLY-7778]) was: Checkout wildfly ladybird and run test: {code} cd testsuite/elytron mvn clean test -Dtest=org.wildfly.test.integration.elytron.ejb.AuthenticationTestCase {code} (need to un-ignore tests tagged as [WFLY-7778]) > Remoting EJB identity propagation does not work with Elytron > ------------------------------------------------------------ > > Key: WFCORE-2392 > URL: https://issues.jboss.org/browse/WFCORE-2392 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron-legacy-test-fails > > Even througth succesful obtaining LoginContext, identity is not propagated in EJB call. > Identity is unauthorized on server side. > *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference. > Often error message: > {code:java} > SaslException: Authentication failed: all available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:10:01 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 15 Mar 2017 13:10:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8131) Aliases in credential stores should be case insensitive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFLY-8131: --------------------------------------- Assignee: ehsavoie Hugonnet (was: Peter Skopek) > Aliases in credential stores should be case insensitive > ------------------------------------------------------- > > Key: WFLY-8131 > URL: https://issues.jboss.org/browse/WFLY-8131 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store, user_experience > > Working with credential store aliases should be case insensitive. > Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase. > E.g. > {code} > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password) > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove() > {code} > *Current behavior:* > First command succeeds and the second fails as the alias is changed to "upper" (in lowercase). > *Expected behavior:* > Both commans succeeds. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8131 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:29:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 15 Mar 2017 13:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-157) Write expressions to logging.properties configuration file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378660#comment-13378660 ] James Perkins commented on WFCORE-157: -------------------------------------- I guess the main issue here will be if a user wants to use a vault value this will not work. We could limit the ability to only write expressions to the file name (maybe level too), but it wouldn't work for {{custom-handler}}'s. I suppose though a vault value wouldn't make much sense anyway as it would be written in plain text to the {{logging.properties}} anyway. > Write expressions to logging.properties configuration file > ---------------------------------------------------------- > > Key: WFCORE-157 > URL: https://issues.jboss.org/browse/WFCORE-157 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > Allow properties that use expressions to write the expression out to the logging.properties configuration file. This allows properties passed in at runtime to affect the initial logging configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:42:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Wed, 15 Mar 2017 13:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-69) Regression Test Hawkular Inventory In-Reply-To: References: Message-ID: Matt Mahoney created HAWKULARQE-69: -------------------------------------- Summary: Regression Test Hawkular Inventory Key: HAWKULARQE-69 URL: https://issues.jboss.org/browse/HAWKULARQE-69 Project: Hawkular QE Issue Type: Task Reporter: Matt Mahoney Assignee: mfoley user Place-holder task, for now. Hawkular Inventory is being redesigned, and expected to be included in the 4.5 release. Will need to regression test around Inventory features. Note: The use of Postgres DB for Inventory data will be going away. Further details are forthcoming. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 13:54:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 15 Mar 2017 13:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8382) Elytron, unable to create custom principal transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFLY-8382: ----------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/161, https://github.com/wildfly-security-incubator/wildfly-core/pull/78 (was: https://github.com/wildfly-security-incubator/wildfly/pull/161) > Elytron, unable to create custom principal transformer > ------------------------------------------------------ > > Key: WFLY-8382 > URL: https://issues.jboss.org/browse/WFLY-8382 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > When I try to register custom principal transformer I get {{NoClassDefFoundError}} > {code} > 07:11:37,203 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.mapper.AddCustomPrincipalTransformerImpl in Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 07:11:37,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 07:11:37,207 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-principal-transformer" => "CreaperTestAddCustomPrincipalTransformer") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer" => "org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module \"org.jboss.customprincipaltransformerimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer"] > } > {code} > That works in DR11 without issue > Here is implementation of used custom prncipal transformer > {code:java|title=AddCustomPrincipalTransformerImpl.java} > package org.wildfly.extras.creaper.commands.elytron.mapper; > import org.wildfly.extension.elytron.Configurable; > import java.security.Principal; > import java.util.Map; > import org.wildfly.extension.elytron.capabilities.PrincipalTransformer; > public class AddCustomPrincipalTransformerImpl implements PrincipalTransformer, Configurable { > @Override > public Principal apply(Principal p) { > return p; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 14:25:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 15 Mar 2017 14:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2537) ModelControllerMBeanTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2537: ----------------------------------------- Assignee: ehsavoie Hugonnet > ModelControllerMBeanTestCase fails with security manager in WF core > ------------------------------------------------------------------- > > Key: WFCORE-2537 > URL: https://issues.jboss.org/browse/WFCORE-2537 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase#testDeploymentViaJmx* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=ModelControllerMBeanTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:53:17,762 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]" "registerMBean")" in code source "(vfs:/content/test-jmx.jar )" of "ModuleClassLoader for Module "deployment.test-jmx.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]" "registerMBean")" in code source "(vfs:/content/test-jmx.jar )" of "ModuleClassLoader for Module "deployment.test-jmx.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 14:26:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Wed, 15 Mar 2017 14:26:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2536) JmxSensitiveTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2536: ----------------------------------------- Assignee: ehsavoie Hugonnet > JmxSensitiveTestCase fails with security manager in WF core > ----------------------------------------------------------- > > Key: WFCORE-2536 > URL: https://issues.jboss.org/browse/WFCORE-2536 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.jboss.as.test.integration.mgmt.access.JmxSensitiveTestCase* > {{cd testsuite/rbac/}} > {{mvn test -Dtest=JmxSensitiveTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:42:13,573 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 16:05:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 15 Mar 2017 16:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378703#comment-13378703 ] Brian Stansberry commented on WFCORE-2497: ------------------------------------------ [~dlofthouse] The way the WFCORE-1106 stuff works, if the child provides it's own capability, a parent resource being reload-required would only prevent Stage.RUNTIME execution by the child resource if the child's capability depends on the parent's. So no, there is no implicit dependency. For Core 4 we could consider auto-adding such a dependency as a programming convenience, perhaps following rules similar to what WFCORE-1106 did for finding letting children without capabilities find ones registered by the parent. I'll think a bit about how hard that would be to do sooner, but I'm concerned about cramming stuff in late in the cycle. > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 16:15:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 15 Mar 2017 16:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2540) Update JACC Version property name and version to match WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378705#comment-13378705 ] Brian Stansberry commented on WFCORE-2540: ------------------------------------------ [~dlofthouse] We already hacked this with vault support, which is declared in the core schemas but won't actually work in core due to the missing picketbox. It's not great but I don't think it's the end of the world either. Better documentation than we have would be good though. I have my doubts whether hiding the API is actually an improvement. If I want to do something and the API is just missing, I think "Huh? Where did it go?" Whereas if I try and it fails with a useful error message, I can take meaningful action. > Update JACC Version property name and version to match WildFly > -------------------------------------------------------------- > > Key: WFCORE-2540 > URL: https://issues.jboss.org/browse/WFCORE-2540 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > > (The definition in WildFly can likely be removed as well) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 16:32:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 15 Mar 2017 16:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2543) Upgrade JBoss Logging from 3.3.0.Final to 3.3.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved JBEAP-9609 to WFCORE-2543: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2543 (was: JBEAP-9609) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) > Upgrade JBoss Logging from 3.3.0.Final to 3.3.1.Final > ----------------------------------------------------- > > Key: WFCORE-2543 > URL: https://issues.jboss.org/browse/WFCORE-2543 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 16:42:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 15 Mar 2017 16:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8387) EJB remote invocations always execute in IO worker even when not supposed to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9610 to WFLY-8387: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8387 (was: JBEAP-9610) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.1.0.DR13) Affects Testing: (was: Regression) > EJB remote invocations always execute in IO worker even when not supposed to > ---------------------------------------------------------------------------- > > Key: WFLY-8387 > URL: https://issues.jboss.org/browse/WFLY-8387 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > > When you configure EJB3 subsystem so that remote invocations should be executed in thread pools of EJB3 subsystem instead of IO worker threads: > {noformat} > /subsystem=ejb3/service=remote:write-attribute(name=execute-in-worker,value=false) > {noformat} > This seems to have no effect and invocations are still executed in IO worker threads. > This is a regression, in EAP 7.0 it works correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 18:25:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 15 Mar 2017 18:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1337) Provide capabilities for paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1337: ------------------------------------- Issue Type: Bug (was: Enhancement) > Provide capabilities for paths > ------------------------------ > > Key: WFCORE-1337 > URL: https://issues.jboss.org/browse/WFCORE-1337 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > We need to be able to do reference validation for capabilities to avoid problems like WFCORE-1333. > This is going to take careful thought though. The PathManager is a bit of a complex beast. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 18:51:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 15 Mar 2017 18:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2406) Credential store alias with upper-case letters can't be added when Java assertions are enabled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2406: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Brian Stansberry) > Credential store alias with upper-case letters can't be added when Java assertions are enabled > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-2406 > URL: https://issues.jboss.org/browse/WFCORE-2406 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > > When Java assertions are enable then adding credential store entry (alias) with upper case letters fails with assertion error. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 19:27:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 15 Mar 2017 19:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-121) Static initializer of class org.apache.log4j.helpers.Loader relies on obsolete java versioning scheme In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-121. ----------------------------------- Resolution: Done This was fixed with PR https://github.com/jboss-logging/log4j-jboss-logmanager/pull/14 > Static initializer of class org.apache.log4j.helpers.Loader relies on obsolete java versioning scheme > ----------------------------------------------------------------------------------------------------- > > Key: JBLOGGING-121 > URL: https://issues.jboss.org/browse/JBLOGGING-121 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-log4j > Reporter: Richard Opalka > Assignee: James Perkins > > JDK9 will introduce new java versioning scheme, see JEP-223 > http://openjdk.java.net/jeps/223 > Please update static initializer of class org.apache.log4j.helpers.Loader accordingly > to ensure smooth JDK9 migration. ATM the initializer will not handle Java 9 properly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 19:36:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 15 Mar 2017 19:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2544) Upgrade log4j-jboss-logmanager from 1.1.2.Final to 1.1.3.Final In-Reply-To: References: Message-ID: James Perkins created WFCORE-2544: ------------------------------------- Summary: Upgrade log4j-jboss-logmanager from 1.1.2.Final to 1.1.3.Final Key: WFCORE-2544 URL: https://issues.jboss.org/browse/WFCORE-2544 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins This includes a fix to allow the {{org.apache.log4j.helpers.Loader}} work with JEP-223. Also includes a fix to ensure the {{LoggingEvent.getThrowableInformation()}} returns {{null}} if the cause is {{null}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 19:54:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 15 Mar 2017 19:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2461) Credential-store attribute relative-to doesn't reference path as required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378747#comment-13378747 ] Ilia Vassilev commented on WFCORE-2461: --------------------------------------- credential-store doesn't define "path" so this is not relevant. (see JBEAP-6935 and JBEAP-8180) When researching the issue I noticed that we have description for property "elytron.credential-store.path" which should be removed. > Credential-store attribute relative-to doesn't reference path as required > ------------------------------------------------------------------------- > > Key: WFCORE-2461 > URL: https://issues.jboss.org/browse/WFCORE-2461 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ilia Vassilev > > Combination of {{path}} and {{relative-to}} attributes is common across all the elytron subsystem. All but one {{relative-to}} attributes list the "path" as required: > {code} > "relative-to" => { > "type" => STRING, > ... > "requires" => ["path"], > ... > } > {code} > The credential-store configuration doesn't define this dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 22:00:01 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 15 Mar 2017 22:00:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1005) Incompatible handling of digest-uri from legacy clients. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved ELY-1005. --------------------------------- Resolution: Done > Incompatible handling of digest-uri from legacy clients. > -------------------------------------------------------- > > Key: ELY-1005 > URL: https://issues.jboss.org/browse/ELY-1005 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.1.0.Beta29 > Reporter: Darran Lofthouse > Assignee: Stuart Douglas > Priority: Blocker > Fix For: 1.1.0.Beta32 > > > When using the jboss-remote-naming library from EAP 7.0 against EAP 7.1.0.DR13 the client is unable to authenticate and all lookups time out ( {{java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS}} ) > The exact same client code with the same dependencies works when running against EAP 7.1. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 15 22:07:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 15 Mar 2017 22:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8383) The current JBoss EAP version is not load balancing websocket requests when using Undertow as a load balancer when mod_cluster is used. This causes all websocket sessions to be created at a single backend server. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas closed WFLY-8383. -------------------------------- Resolution: Rejected > The current JBoss EAP version is not load balancing websocket requests when using Undertow as a load balancer when mod_cluster is used. This causes all websocket sessions to be created at a single backend server. > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8383 > URL: https://issues.jboss.org/browse/WFLY-8383 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: David Mulford > Assignee: Stuart Douglas > > User is looking for functionality similar to that of mod_proxy_wstunnel for Apache httpd, and wants this in Undertow's mod_cluster implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 02:31:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 16 Mar 2017 02:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-70) Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server In-Reply-To: References: Message-ID: Sunil kondkar created HAWKULARQE-70: --------------------------------------- Summary: Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server Key: HAWKULARQE-70 URL: https://issues.jboss.org/browse/HAWKULARQE-70 Project: Hawkular QE Issue Type: Task Reporter: Sunil kondkar Assignee: mfoley user Need of the task: To make sure the CFME docker instance that we use on Jenkins nightly run has CFME containers always running, we use docker scripts. These are existing shell scripts which are using old methods to create cfme docker container and then start the cfme instance which are irrelevant now: These are located at: https://github.com/Hawkular-QE/cf-ui/tree/master/scripts/automation/docker This task is to: 1) Modify the scripts (common.sh, start.sh) to: -Stop the CFME instance -Start the CFME instance -Check if the URL is ready using curl -Check the logs if CFME is started 2) Git clone the modified scripts to CFME server 3) Execute the scripts on CFME server ( Use 'execute shell script' on Jenkins nightly job to ssh/git clone and execute script on CFME server) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 02:32:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 16 Mar 2017 02:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-70) Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar reassigned HAWKULARQE-70: --------------------------------------- Assignee: Sunil kondkar (was: mfoley user) > Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server > --------------------------------------------------------------------------------- > > Key: HAWKULARQE-70 > URL: https://issues.jboss.org/browse/HAWKULARQE-70 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Need of the task: > To make sure the CFME docker instance that we use on Jenkins nightly run has CFME containers always running, we use docker scripts. > These are existing shell scripts which are using old methods to create cfme docker container and then start the cfme instance which are irrelevant now: > These are located at: > https://github.com/Hawkular-QE/cf-ui/tree/master/scripts/automation/docker > This task is to: > 1) Modify the scripts (common.sh, start.sh) to: > -Stop the CFME instance > -Start the CFME instance > -Check if the URL is ready using curl > -Check the logs if CFME is started > 2) Git clone the modified scripts to CFME server > 3) Execute the scripts on CFME server > ( Use 'execute shell script' on Jenkins nightly job to ssh/git clone and execute script on CFME server) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 03:38:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 16 Mar 2017 03:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-928) CLI is not terminated correctly with invalid address on HPUX In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise closed WFCORE-928. --------------------------------------- Resolution: Cannot Reproduce Bug > CLI is not terminated correctly with invalid address on HPUX > ------------------------------------------------------------ > > Key: WFCORE-928 > URL: https://issues.jboss.org/browse/WFCORE-928 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Beta4 > Reporter: Marek Kopeck? > Assignee: Jean-Francois Denise > Priority: Minor > > *Description of problem:* > CLI is not terminated correctly with invalid address on HPUX. > *How reproducible:* > Always on HPUX > *Steps to Reproduce:* > # ./jboss-cli.sh -c --controller=nonsence > *Actual results:* > CLI is terminated after input on stdin. > *Expected results:* > CLI is terminated correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 05:23:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 16 Mar 2017 05:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2164) Probe: option {{-addr}} doesn't work In-Reply-To: References: Message-ID: Bela Ban created JGRP-2164: ------------------------------ Summary: Probe: option {{-addr}} doesn't work Key: JGRP-2164 URL: https://issues.jboss.org/browse/JGRP-2164 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0.2 First off, IPv6 addresses are not parsed correctly. Second, "addrs" as keyword is too generic, change this to "member-addrs". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 05:23:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 16 Mar 2017 05:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2164) Probe: option -addr doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2164: --------------------------- Summary: Probe: option -addr doesn't work (was: Probe: option {{-addr}} doesn't work) > Probe: option -addr doesn't work > -------------------------------- > > Key: JGRP-2164 > URL: https://issues.jboss.org/browse/JGRP-2164 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.2 > > > First off, IPv6 addresses are not parsed correctly. Second, "addrs" as keyword is too generic, change this to "member-addrs". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 05:24:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 16 Mar 2017 05:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2164) Probe: option -addr doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-2164. ---------------------------- Resolution: Done > Probe: option -addr doesn't work > -------------------------------- > > Key: JGRP-2164 > URL: https://issues.jboss.org/browse/JGRP-2164 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.2 > > > First off, IPv6 addresses are not parsed correctly. Second, "addrs" as keyword is too generic, change this to "member-addrs". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:01:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Thu, 16 Mar 2017 07:01:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8388) Remove version.org.wildfly.security.elytron-subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan moved JBEAP-9618 to WFLY-8388: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8388 (was: JBEAP-9618) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Remove version.org.wildfly.security.elytron-subsystem > ----------------------------------------------------- > > Key: WFLY-8388 > URL: https://issues.jboss.org/browse/WFLY-8388 > Project: WildFly > Issue Type: Bug > Reporter: Kabir Khan > Assignee: Kabir Khan > > The pom still contains an unused version.org.wildfly.security.elytron-subsystem. The elytron subsystem now comes in via core -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:04:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Thu, 16 Mar 2017 07:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8388) Remove version.org.wildfly.security.elytron-subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan deleted WFLY-8388: ----------------------------- > Remove version.org.wildfly.security.elytron-subsystem > ----------------------------------------------------- > > Key: WFLY-8388 > URL: https://issues.jboss.org/browse/WFLY-8388 > Project: WildFly > Issue Type: Bug > Reporter: Kabir Khan > Assignee: Kabir Khan > > The pom still contains an unused version.org.wildfly.security.elytron-subsystem. The elytron subsystem now comes in via core -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:21:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Thu, 16 Mar 2017 07:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-945) User names in Elytron FileSystemRealm are not case sensitive on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378932#comment-13378932 ] Bartosz Baranowski commented on ELY-945: ---------------------------------------- Given that implementation relies on Path(Path p = p.resolve(next)), this is JDK bug. Not much can be done aside of lower casing everything. > User names in Elytron FileSystemRealm are not case sensitive on Windows > ----------------------------------------------------------------------- > > Key: ELY-945 > URL: https://issues.jboss.org/browse/ELY-945 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Bartosz Baranowski > Priority: Blocker > > User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}} > This is IMO a security issue. And it also affects platform certifications. > If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:21:01 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 16 Mar 2017 07:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-71) Test Hawkular Java Agent In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-71: ---------------------------------------- Summary: Test Hawkular Java Agent Key: HAWKULARQE-71 URL: https://issues.jboss.org/browse/HAWKULARQE-71 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: mfoley user Priority: Minor There is a new Java Agent (HJA) that you can run in any JVM (including but not limited to EAP-based projects). You do so by passing in a "-javaagent" command line option to your JVM (e.g. java -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar ...yadda...). There are two additional properties you must set in standalone.conf if you want to run it inside an EAP JVM. The README will have the details. This new HJA is configured with a yaml file that largely mimics all the standalone.xml data that HWFA has. There is no ${x} support in the YAML file right now. This new HJA can talk to any EAP or WildFly server over the DMR management API. It can do deployments to your EAP/WildFly servers and monitoring of EAP/WildFly subsystems just like HWFA can. This new HJA can talk to any JMX server just like HWFA can (it will talk to the local MBeanServer or, if remotely monitoring a JMX server, it will talk to it over Jolokia/REST API). This new HJA can NOT run directly inside of a Host Controller due to https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA externally in its own JVM (e.g. java -jar hawkular-javaagent.jar config=config.yaml) and have its config.yaml point to a remote Host Controller and you'll get the same functionality. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:24:00 2017 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Thu, 16 Mar 2017 07:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8389) Settings modcluster/ssl-context conflict issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov moved JBEAP-9619 to WFLY-8389: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8389 (was: JBEAP-9619) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: mod_cluster (was: mod_cluster) (was: User Experience) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR12) (was: 7.1.0.DR13) > Settings modcluster/ssl-context conflict issue > ---------------------------------------------- > > Key: WFLY-8389 > URL: https://issues.jboss.org/browse/WFLY-8389 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 11.0.0.Alpha1 > Reporter: Michal Petrov > Assignee: Radoslav Husar > > Setting ssl-context in modcluster subsystem > {noformat} > /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=ssl-context,value=clientSSLContext) > {noformat} > when ssl is configured > {noformat} > /subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration > {noformat} > shouldn't end as success > {noformat} > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} > as {noformat}reload{noformat} > triggers exception in server log > {noformat} > 2017-03-13 10:13:45,394 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 51) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]): java.lang.IllegalStateException: WFLYMODCLS0020: Only one of 'ssl-context' attribute or 'ssl' resource can be defined! > at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.configure(ModClusterConfigurationServiceBuilder.java:225) > at org.wildfly.extension.mod_cluster.ModClusterSubsystemAdd.performBoottime(ModClusterSubsystemAdd.java:80) > at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performBoottime(AbstractBoottimeAddStepHandler.java:157) > at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:116) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:381) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} > User shouldn't be allowed to set ssl-context in this scenario or be warned. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:24:00 2017 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Thu, 16 Mar 2017 07:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8389) Settings modcluster/ssl-context conflict issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov reassigned WFLY-8389: ----------------------------------- Assignee: Michal Petrov (was: Radoslav Husar) > Settings modcluster/ssl-context conflict issue > ---------------------------------------------- > > Key: WFLY-8389 > URL: https://issues.jboss.org/browse/WFLY-8389 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 11.0.0.Alpha1 > Reporter: Michal Petrov > Assignee: Michal Petrov > > Setting ssl-context in modcluster subsystem > {noformat} > /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=ssl-context,value=clientSSLContext) > {noformat} > when ssl is configured > {noformat} > /subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration > {noformat} > shouldn't end as success > {noformat} > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} > as {noformat}reload{noformat} > triggers exception in server log > {noformat} > 2017-03-13 10:13:45,394 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 51) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]): java.lang.IllegalStateException: WFLYMODCLS0020: Only one of 'ssl-context' attribute or 'ssl' resource can be defined! > at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.configure(ModClusterConfigurationServiceBuilder.java:225) > at org.wildfly.extension.mod_cluster.ModClusterSubsystemAdd.performBoottime(ModClusterSubsystemAdd.java:80) > at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performBoottime(AbstractBoottimeAddStepHandler.java:157) > at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:116) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:381) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} > User shouldn't be allowed to set ssl-context in this scenario or be warned. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:51:00 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 07:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda updated WFLY-6607: ---------------------------------- Component/s: (was: Web Console) > Broadcast/Discovery group is possible to create with just a name > ---------------------------------------------------------------- > > Key: WFLY-6607 > URL: https://issues.jboss.org/browse/WFLY-6607 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Chen Maoqian > Assignee: Chao Wang > > When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default > user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one) > At this moment it's possible to create broadcast group with just a name which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:52:00 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 07:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13378957#comment-13378957 ] Claudio Miranda commented on WFLY-6607: --------------------------------------- I removed the Web Console from component list, as I fixed them in HAL, however CLI accepts to create the resource with just a name. > Broadcast/Discovery group is possible to create with just a name > ---------------------------------------------------------------- > > Key: WFLY-6607 > URL: https://issues.jboss.org/browse/WFLY-6607 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Chen Maoqian > Assignee: Chao Wang > > When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default > user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one) > At this moment it's possible to create broadcast group with just a name which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:54:00 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 07:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6024) The management console cannot display more than 5 runtime datasources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-6024. --------------------------------- Assignee: Claudio Miranda (was: Heiko Braun) Resolution: Cannot Reproduce Bug As the reporter said in the comment, it is working. > The management console cannot display more than 5 runtime datasources > --------------------------------------------------------------------- > > Key: WFLY-6024 > URL: https://issues.jboss.org/browse/WFLY-6024 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 9.0.2.Final > Reporter: Laurent Pereira > Assignee: Claudio Miranda > Priority: Minor > Attachments: wildfly-console-runtime-datasource.PNG > > > From the runtime tab of the management console : I cannot display more than 5 datasources although more than 6 have been defined. > As a consequence, it is not possible to manage the missing datasources. > Sample screenshot : > !wildfly-console-runtime-datasource.PNG|thumbnail! > 5 datasources of 7 are displayed. 2 datasources are always hidden. No scroll available. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:57:00 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 07:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-5376. --------------------------------- Assignee: Claudio Miranda (was: Heiko Braun) Resolution: Cannot Reproduce Bug Cannot reproduce the problem, if you feel this is wrong reopen please. > poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab > -------------------------------------------------------------------------- > > Key: WFLY-5376 > URL: https://issues.jboss.org/browse/WFLY-5376 > Project: WildFly > Issue Type: Enhancement > Components: Web Console > Affects Versions: 10.0.0.CR1 > Reporter: The Alchemist > Assignee: Claudio Miranda > Priority: Minor > Attachments: screenshot-1.png > > > h2. Screenshot > !screenshot-1.png! > h2. Specs > * Mac OS X 10.10.5 > * MacBook Pro (Retina, 15-inch, Late 2013) > * Chrome 45.0.2454.93 (64-bit) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 07:57:01 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 07:57:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5746) Dropdown button of admin console is not working properly on Chrome( work ok on Firefox) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-5746. --------------------------------- Assignee: Claudio Miranda (was: Heiko Braun) Resolution: Cannot Reproduce Bug Cannot reproduce the problem, if you feel this is wrong reopen please. > Dropdown button of admin console is not working properly on Chrome( work ok on Firefox) > --------------------------------------------------------------------------------------- > > Key: WFLY-5746 > URL: https://issues.jboss.org/browse/WFLY-5746 > Project: WildFly > Issue Type: Enhancement > Components: Web Console > Affects Versions: 10.0.0.CR4 > Reporter: Sun Chanras > Assignee: Claudio Miranda > Priority: Minor > > dropdown button of wildfly admin console is not working properly, though it work good on FireFox. > I found it very difficult to click on dropdown button to upload , remove ,deploy etc. > But the problem does not exist on Firefox. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 08:00:01 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 08:00:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6843) Buttons at the end of modal panels get cut off In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-6843. --------------------------------- Resolution: Done As HAL-1132 is resolved, I will resolve this too. > Buttons at the end of modal panels get cut off > ---------------------------------------------- > > Key: WFLY-6843 > URL: https://issues.jboss.org/browse/WFLY-6843 > Project: WildFly > Issue Type: Bug > Components: Web Console > Reporter: Bartosz Baranowski > Assignee: Michal Petrov > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 08:11:01 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 08:11:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5504) Servers are missing in the list of servers in a server group in the web console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-5504. --------------------------------- Assignee: Claudio Miranda (was: Heiko Braun) Resolution: Cannot Reproduce Bug Cannot reproduce the problem, if you feel this is wrong, reopen please. > Servers are missing in the list of servers in a server group in the web console > ------------------------------------------------------------------------------- > > Key: WFLY-5504 > URL: https://issues.jboss.org/browse/WFLY-5504 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 10.0.0.CR2 > Environment: Debian 8, Java 8u60, wildfly 10.0.0.CR2 in domain mode > Reporter: Thiago Presa > Assignee: Claudio Miranda > Attachments: bug1.png, bug3.png, bug4.png > > > I created a server-group for an application in a wildfly running in domain mode. This wildfly cluster is composed of a master node and two slave nodes. > I then created two servers in this server group in the two slave nodes. > When I ask through the web console to view details of those servers, they show up correctly: > !bug1.png|thumbnail! > !bug4.png|thumbnail! > However, when listing the servers in the cdl server group, only one of them is listed: > !bug3.png|thumbnail! > As far as I've checked, XMLs are OK, there are no Exceptions in the logs and the application is running fine. Please let me know if further info is necessary. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 08:16:01 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 16 Mar 2017 08:16:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6842) Impossible to read/configure messaging provider journal directory path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-6842. --------------------------------- Resolution: Done As HAL-1137 is resolved, this should be resolved too. > Impossible to read/configure messaging provider journal directory path > ---------------------------------------------------------------------- > > Key: WFLY-6842 > URL: https://issues.jboss.org/browse/WFLY-6842 > Project: WildFly > Issue Type: Bug > Components: Web Console > Reporter: Bartosz Baranowski > Assignee: Michal Petrov > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:11:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 16 Mar 2017 09:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-72) Polarion data cleanup In-Reply-To: References: Message-ID: Sunil kondkar created HAWKULARQE-72: --------------------------------------- Summary: Polarion data cleanup Key: HAWKULARQE-72 URL: https://issues.jboss.org/browse/HAWKULARQE-72 Project: Hawkular QE Issue Type: Task Reporter: Sunil kondkar Assignee: Michael Foley Task to able to have polarion reports in place. Reports: 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports 3) Test Run Status by Plan 4) Test Run Status by Plan and chosen fields Tasks: 1) Find and remove duplicates 2) Each test case has correct fields -Description - Level - Test type and sub type - Automated or Manual - Importance (Severity) 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans 4) Check if manual test cases are with approved status( Approve if needed) 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. (Need to check if we can have the polarion export job marking it Approved while executed going forward?) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:12:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 16 Mar 2017 09:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-72) Polarion data cleanup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar reassigned HAWKULARQE-72: --------------------------------------- Assignee: Sunil kondkar (was: Michael Foley) > Polarion data cleanup > --------------------- > > Key: HAWKULARQE-72 > URL: https://issues.jboss.org/browse/HAWKULARQE-72 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to able to have polarion reports in place. > Reports: > 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics > 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports > 3) Test Run Status by Plan > 4) Test Run Status by Plan and chosen fields > Tasks: > 1) Find and remove duplicates > 2) Each test case has correct fields > -Description > - Level > - Test type and sub type > - Automated or Manual > - Importance (Severity) > 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) > Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans > 4) Check if manual test cases are with approved status( Approve if needed) > 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. > (Need to check if we can have the polarion export job marking it Approved while executed going forward?) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:15:01 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 16 Mar 2017 09:15:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1006) Elytron Audit Logging does not support log file rotation In-Reply-To: References: Message-ID: Jan Tymel created ELY-1006: ------------------------------ Summary: Elytron Audit Logging does not support log file rotation Key: ELY-1006 URL: https://issues.jboss.org/browse/ELY-1006 Project: WildFly Elytron Issue Type: Bug Reporter: Jan Tymel Assignee: Darran Lofthouse Priority: Blocker It is not possible to rotate (= rename current log file and start logging into a new one) Elytron Audit log files. It cannot be set to use the log rotation neither based on the file size (e.g. once the file size outreaches 100 MB) nor based on a time period (e.g. rotate create a new file every Sunday at midnight). Inability to set the log rotation could lead to huge log files. Then it would be really difficult to read such files. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:20:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 16 Mar 2017 09:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1006) Elytron Audit Logging does not support log file rotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reassigned ELY-1006: ------------------------------ Assignee: (was: Darran Lofthouse) > Elytron Audit Logging does not support log file rotation > -------------------------------------------------------- > > Key: ELY-1006 > URL: https://issues.jboss.org/browse/ELY-1006 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Blocker > Attachments: deployment.war > > > It is not possible to rotate (= rename current log file and start logging into a new one) Elytron Audit log files. It cannot be set to use the log rotation neither based on the file size (e.g. once the file size outreaches 100 MB) nor based on a time period (e.g. rotate create a new file every Sunday at midnight). > Inability to set the log rotation could lead to huge log files. Then it would be really difficult to read such files. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:20:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 16 Mar 2017 09:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1006) Elytron Audit Logging does not support log file rotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated ELY-1006: --------------------------- Attachment: deployment.war > Elytron Audit Logging does not support log file rotation > -------------------------------------------------------- > > Key: ELY-1006 > URL: https://issues.jboss.org/browse/ELY-1006 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Blocker > Attachments: deployment.war > > > It is not possible to rotate (= rename current log file and start logging into a new one) Elytron Audit log files. It cannot be set to use the log rotation neither based on the file size (e.g. once the file size outreaches 100 MB) nor based on a time period (e.g. rotate create a new file every Sunday at midnight). > Inability to set the log rotation could lead to huge log files. Then it would be really difficult to read such files. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:26:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 16 Mar 2017 09:26:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-70) Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13379030#comment-13379030 ] Sunil kondkar commented on HAWKULARQE-70: ----------------------------------------- 1) Created scripts: Commits: https://github.com/Hawkular-QE/cf-ui/compare/dockerscripts 2) Created new CFME instance for test on openstack (to be able to use yum and git): 10.8.184.58 3) Configured Jenkins Job to experiment: http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/miq-ms-cfui-nightly-test/ -Added ssh site 10.8.184.58 to Jenkins global configuration and tested that the instance can be ssh'ed -Added commands in jenkins job to git clone and check URL if working correctly (This is under test and working partly) PR to be sent once all tests pass. > Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server > --------------------------------------------------------------------------------- > > Key: HAWKULARQE-70 > URL: https://issues.jboss.org/browse/HAWKULARQE-70 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Need of the task: > To make sure the CFME docker instance that we use on Jenkins nightly run has CFME containers always running, we use docker scripts. > These are existing shell scripts which are using old methods to create cfme docker container and then start the cfme instance which are irrelevant now: > These are located at: > https://github.com/Hawkular-QE/cf-ui/tree/master/scripts/automation/docker > This task is to: > 1) Modify the scripts (common.sh, start.sh) to: > -Stop the CFME instance > -Start the CFME instance > -Check if the URL is ready using curl > -Check the logs if CFME is started > 2) Git clone the modified scripts to CFME server > 3) Execute the scripts on CFME server > ( Use 'execute shell script' on Jenkins nightly job to ssh/git clone and execute script on CFME server) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:31:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 16 Mar 2017 09:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1007) Exception in authenticate() method of SecurityContextImpl is hidden In-Reply-To: References: Message-ID: Ondrej Lukas created ELY-1007: --------------------------------- Summary: Exception in authenticate() method of SecurityContextImpl is hidden Key: ELY-1007 URL: https://issues.jboss.org/browse/ELY-1007 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when {{authenticator.authenticate()}} in {{authenticate()}} method of {{org.wildfly.elytron.web.undertow.server.SecurityContextImpl}} [1] throws exception, then this exception is hidden and only internal server error status is returned. Thrown exception should be logged. This issue can be cause of JBEAP-9377. [1] https://github.com/wildfly-security/elytron-web/blob/49241df4afcc37158c54959fd52b8b5b619f2209/undertow/src/main/java/org/wildfly/elytron/web/undertow/server/SecurityContextImpl.java#L97 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:35:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 16 Mar 2017 09:35:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2545) Principal with null name causes hidden NPE for chained-principal-transformer In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2545: ------------------------------------ Summary: Principal with null name causes hidden NPE for chained-principal-transformer Key: WFCORE-2545 URL: https://issues.jboss.org/browse/WFCORE-2545 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when Principal with null name is used in {{chain}} of {{org.wildfly.extension.elytron.capabilities.PrincipalTransformer}} then this method throw NullPointerException which is hidden to user due to JBEAP-9625. This issue can be simply reproduced by using regex-validating-principal-transformer and user which does not match given pattern. Then Principal name is set to null which results to following NPE: {code} java.lang.NullPointerException: java.util.regex.Matcher.getTextLength(Matcher.java:1283) java.util.regex.Matcher.reset(Matcher.java:309) java.util.regex.Matcher.(Matcher.java:229) java.util.regex.Pattern.matcher(Pattern.java:1093) org.wildfly.security.auth.util.RegexNameRewriter.rewriteName(RegexNameRewriter.java:55) org.wildfly.security.auth.server.NameRewriter.lambda$asPrincipalRewriter$1(NameRewriter.java:63) org.wildfly.extension.elytron.capabilities.PrincipalTransformer.lambda$chain$1(PrincipalTransformer.java:64) ... {code} Since there is no related documentation or javadoc it is also possible that issue is rather in regex-validating-principal-transformer which could set Principal to null instead of Principal name to null. It must be clarified by engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:36:01 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 16 Mar 2017 09:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-72) Polarion data cleanup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar updated HAWKULARQE-72: ------------------------------------ Description: Task to able to have polarion reports in place. Reports: 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports 3) Test Run Status by Plan 4) Test Run Status by Plan and chosen fields Tasks: 1) Find and remove duplicates 2) Each test case has correct fields * Description * Level * Test type and sub type * Automated or Manual * Importance (Severity) 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans 4) Check if manual test cases are with approved status( Approve if needed) 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. (Need to check if we can have the polarion export job marking it Approved while executed going forward?) was: Task to able to have polarion reports in place. Reports: 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports 3) Test Run Status by Plan 4) Test Run Status by Plan and chosen fields Tasks: 1) Find and remove duplicates 2) Each test case has correct fields -Description - Level - Test type and sub type - Automated or Manual - Importance (Severity) 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans 4) Check if manual test cases are with approved status( Approve if needed) 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. (Need to check if we can have the polarion export job marking it Approved while executed going forward?) > Polarion data cleanup > --------------------- > > Key: HAWKULARQE-72 > URL: https://issues.jboss.org/browse/HAWKULARQE-72 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to able to have polarion reports in place. > Reports: > 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics > 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports > 3) Test Run Status by Plan > 4) Test Run Status by Plan and chosen fields > Tasks: > 1) Find and remove duplicates > 2) Each test case has correct fields > * Description > * Level > * Test type and sub type > * Automated or Manual > * Importance (Severity) > 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) > Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans > 4) Check if manual test cases are with approved status( Approve if needed) > 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. > (Need to check if we can have the polarion export job marking it Approved while executed going forward?) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:38:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 16 Mar 2017 09:38:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2546) Typo in description of Elytron aggregate-principal-transformer In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2546: ------------------------------------ Summary: Typo in description of Elytron aggregate-principal-transformer Key: WFCORE-2546 URL: https://issues.jboss.org/browse/WFCORE-2546 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse There is typo in description of Elytron aggregate-principal-transformer in CLI. There is {{principa}} instead of {{principal}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:41:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 16 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2547: ------------------------------------ Summary: Revisit the meaning of aggregate-principal-transformer Key: WFCORE-2547 URL: https://issues.jboss.org/browse/WFCORE-2547 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:41:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 16 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1008) Elytron Audit Logging does not support logging into more destinations In-Reply-To: References: Message-ID: Jan Tymel created ELY-1008: ------------------------------ Summary: Elytron Audit Logging does not support logging into more destinations Key: ELY-1008 URL: https://issues.jboss.org/browse/ELY-1008 Project: WildFly Elytron Issue Type: Bug Reporter: Jan Tymel Assignee: Darran Lofthouse Priority: Blocker Attachments: deployment.war According to my understanding it is not possible to send Elytron Audit logs to more destinations (files or syslogs). It is caused by {{security-event-listener}} property within {{security-domain}} takes only _string_ attribute and not _list_ of them. Example of use-case that may be affected: I want to send logs to a syslog server AND also as a backup to a file on NFS. This means that if the syslog server will be unreachable, it will still be possible to send logs into a backup file on NFS and therefore no logs will be completely lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:41:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 16 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1008) Elytron Audit Logging does not support logging into more destinations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reassigned ELY-1008: ------------------------------ Assignee: (was: Darran Lofthouse) > Elytron Audit Logging does not support logging into more destinations > --------------------------------------------------------------------- > > Key: ELY-1008 > URL: https://issues.jboss.org/browse/ELY-1008 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Blocker > Attachments: deployment.war > > > According to my understanding it is not possible to send Elytron Audit logs to more destinations (files or syslogs). It is caused by {{security-event-listener}} property within {{security-domain}} takes only _string_ attribute and not _list_ of them. > Example of use-case that may be affected: > I want to send logs to a syslog server AND also as a backup to a file on NFS. This means that if the syslog server will be unreachable, it will still be possible to send logs into a backup file on NFS and therefore no logs will be completely lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:41:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 16 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1008) Elytron Audit Logging does not support logging into more destinations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated ELY-1008: --------------------------- Attachment: deployment.war > Elytron Audit Logging does not support logging into more destinations > --------------------------------------------------------------------- > > Key: ELY-1008 > URL: https://issues.jboss.org/browse/ELY-1008 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Blocker > Attachments: deployment.war > > > According to my understanding it is not possible to send Elytron Audit logs to more destinations (files or syslogs). It is caused by {{security-event-listener}} property within {{security-domain}} takes only _string_ attribute and not _list_ of them. > Example of use-case that may be affected: > I want to send logs to a syslog server AND also as a backup to a file on NFS. This means that if the syslog server will be unreachable, it will still be possible to send logs into a backup file on NFS and therefore no logs will be completely lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 09:45:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Thu, 16 Mar 2017 09:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2548) Native management interface ignores SSL/TLS based on Elytron SSL Context when remote protocol is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek moved JBEAP-9631 to WFCORE-2548: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2548 (was: JBEAP-9631) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta9 (was: 7.1.0.DR14) > Native management interface ignores SSL/TLS based on Elytron SSL Context when remote protocol is used > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-2548 > URL: https://issues.jboss.org/browse/WFCORE-2548 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Kotek > Priority: Blocker > Labels: cli, management, model-controller-client, remoting, ssl, tls > > Following [1] to set management {{native-interface}} backed by SSL Context from Elytron. Using {{remote}} protocol, {{jboss-cli}} connects to server ignoring a need to have trusted client certificate. > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildFlyElytronSecurity-EnableTwowaySSL%2FTLSfortheManagementInterfacesusingtheElytronSubsystem -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:01:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Thu, 16 Mar 2017 10:01:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1009) Default settings of SSL session caching for Elytron *-ssl-context are not safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev moved JBEAP-9633 to ELY-1009: ------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1009 (was: JBEAP-9633) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: SSL (was: Security) Affects Version/s: 1.1.0.Beta29 (was: 7.1.0.DR13) > Default settings of SSL session caching for Elytron *-ssl-context are not safe > ------------------------------------------------------------------------------ > > Key: ELY-1009 > URL: https://issues.jboss.org/browse/ELY-1009 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta29 > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Critical > Labels: default, management-model, ssl, tls > > The default values of {{maximum-session-cache-size}} and {{session-timeout}} of Elytron {{*-ssl-context}} are {{0}}. This is not safe because SSL sessions can be stored indefinitely. Furthermore, such default settings overwrites default settings in Java, which can be unexpected. > There should be reasonable combination of values, or Java default values should be (let) used. > For example, see http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/security/ssl/SSLSessionContextImpl.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:36:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 10:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1010) Additional TRACE logging for MechanismInformationCallback In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1010: ------------------------------------- Summary: Additional TRACE logging for MechanismInformationCallback Key: ELY-1010 URL: https://issues.jboss.org/browse/ELY-1010 Project: WildFly Elytron Issue Type: Task Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Minor Fix For: 1.1.0.Beta32 Debugging a current issue it would be very helpful within the log to see the MechanismInformation that the callback is transporting. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:40:00 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Thu, 16 Mar 2017 10:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1480) Support timezones in date and type variables In-Reply-To: References: Message-ID: Tibor Zim?nyi created DROOLS-1480: ------------------------------------- Summary: Support timezones in date and type variables Key: DROOLS-1480 URL: https://issues.jboss.org/browse/DROOLS-1480 Project: Drools Issue Type: Enhancement Components: dmn engine Affects Versions: 7.0.0.Beta7 Reporter: Tibor Zim?nyi Assignee: Edson Tirelli Priority: Minor Currently we don't support timezones in date and time variables. This should be implemented, when we are sure about the exact format of timezones. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:42:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 16 Mar 2017 10:42:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2432) Elytron auth method misconfiguration not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reassigned WFCORE-2432: ---------------------------------- Assignee: Jan Kalina > Elytron auth method misconfiguration not logged > ----------------------------------------------- > > Key: WFCORE-2432 > URL: https://issues.jboss.org/browse/WFCORE-2432 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Labels: user_experience > > When deployment is configured to be secured with DIGEST, but {{http-authentication-factory}} does not list DIGEST mechanism, user is not informed about misconfiguration. Even when TRACE logging is turned on. When user tries to access app 403 http code is returned and Forbidden is shown in browser. I would expect browser dialog to appear to allow user provide credentials (401 http status code). > {code:title=web.xml} > > DIGEST > ApplicaitonRealm > > {code} > {code:title=standalone-elytron.xml} > > > > > > > > > {code} > This applies globally to all authentication mechanisms, not only DIGEST. > Could elytron handle misconfiguration: > * either fail during deploying application as deployment requirement can't be satisfy > * or provide reasonable elytron defaults of missing mechanism configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:50:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 16 Mar 2017 10:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2432) Elytron auth method misconfiguration not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2432: ------------------------------- Priority: Blocker (was: Critical) > Elytron auth method misconfiguration not logged > ----------------------------------------------- > > Key: WFCORE-2432 > URL: https://issues.jboss.org/browse/WFCORE-2432 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Labels: user_experience > > When deployment is configured to be secured with DIGEST, but {{http-authentication-factory}} does not list DIGEST mechanism, user is not informed about misconfiguration. Even when TRACE logging is turned on. When user tries to access app 403 http code is returned and Forbidden is shown in browser. I would expect browser dialog to appear to allow user provide credentials (401 http status code). > {code:title=web.xml} > > DIGEST > ApplicaitonRealm > > {code} > {code:title=standalone-elytron.xml} > > > > > > > > > {code} > This applies globally to all authentication mechanisms, not only DIGEST. > Could elytron handle misconfiguration: > * either fail during deploying application as deployment requirement can't be satisfy > * or provide reasonable elytron defaults of missing mechanism configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:56:01 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 16 Mar 2017 10:56:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, kerberos-security-factory unintentionaly required attribute "options" In-Reply-To: References: Message-ID: Martin Choma created WFCORE-2549: ------------------------------------ Summary: Elytron, kerberos-security-factory unintentionaly required attribute "options" Key: WFCORE-2549 URL: https://issues.jboss.org/browse/WFCORE-2549 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker *User impact:* User can't configure kerberos authentication without optional {{options}} attribute *Workaround:* Add any option, even if you don't need any. {code} /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {code} *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} Not setting as alpha blocker, as workaround exists. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 10:57:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 16 Mar 2017 10:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1480) Support timezones in date and type variables In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13379118#comment-13379118 ] Edson Tirelli commented on DROOLS-1480: --------------------------------------- Thank you for creating this. I am hoping we get a clarification on timezones support in DMN 1.2. I am not expecting this to be solved in DMN 1.1. > Support timezones in date and type variables > -------------------------------------------- > > Key: DROOLS-1480 > URL: https://issues.jboss.org/browse/DROOLS-1480 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zim?nyi > Assignee: Edson Tirelli > Priority: Minor > Labels: reported-by-qe > > Currently we don't support timezones in date and time variables. This should be implemented, when we are sure about the exact format of timezones. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 11:05:02 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 16 Mar 2017 11:05:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, kerberos-security-factory unintentionaly required attribute "options" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFCORE-2549: --------------------------------- Labels: (was: eap71_beta kerberos) > Elytron, kerberos-security-factory unintentionaly required attribute "options" > ------------------------------------------------------------------------------ > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication without optional {{options}} attribute > *Workaround:* Add any option, even if you don't need any. > {code} > /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {code} > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} > Not setting as alpha blocker, as workaround exists. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 11:07:02 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 16 Mar 2017 11:07:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1011) Failed validation in regex-validating-principal-transformer causes NPE for Elytron audit logging In-Reply-To: References: Message-ID: Ondrej Lukas created ELY-1011: --------------------------------- Summary: Failed validation in regex-validating-principal-transformer causes NPE for Elytron audit logging Key: ELY-1011 URL: https://issues.jboss.org/browse/ELY-1011 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when validation in Elytron regex-validating-principal-transformer fails then following NPE occurs in server log: {code} ERROR [org.wildfly.security] (default task-2) ELY01094: An event handler threw an exception: java.lang.NullPointerException: Value in JsonObjects name/value pair cannot be null at org.glassfish.json.JsonObjectBuilderImpl.validateValue(JsonObjectBuilderImpl.java:164) at org.glassfish.json.JsonObjectBuilderImpl.add(JsonObjectBuilderImpl.java:74) at org.wildfly.security.audit.JsonSecurityEventFormatter.handleAuthenticationFailedEvent(JsonSecurityEventFormatter.java:99) at org.wildfly.security.audit.JsonSecurityEventFormatter.handleAuthenticationFailedEvent(JsonSecurityEventFormatter.java:93) at org.wildfly.security.audit.JsonSecurityEventFormatter.handleAuthenticationFailedEvent(JsonSecurityEventFormatter.java:43) at org.wildfly.security.auth.server.event.SecurityAuthenticationFailedEvent.accept(SecurityAuthenticationFailedEvent.java:49) at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:680) at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:687) at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.fail(ServerAuthenticationContext.java:1793) at org.wildfly.security.auth.server.ServerAuthenticationContext.fail(ServerAuthenticationContext.java:433) at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:865) at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.fail(UsernamePasswordAuthenticationMechanism.java:107) at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:170) at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:97) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) 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) {code} It happens only in case when Elytron audit log is enabled. It happens in case when match attribute is set to true and principal name does not match given pattern as well as in case when match attribute is set to false and principal name matches given pattern. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 11:44:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 11:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1008) Elytron Audit Logging does not support logging into more destinations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned ELY-1008: ------------------------------------- Assignee: Darran Lofthouse > Elytron Audit Logging does not support logging into more destinations > --------------------------------------------------------------------- > > Key: ELY-1008 > URL: https://issues.jboss.org/browse/ELY-1008 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: deployment.war > > > According to my understanding it is not possible to send Elytron Audit logs to more destinations (files or syslogs). It is caused by {{security-event-listener}} property within {{security-domain}} takes only _string_ attribute and not _list_ of them. > Example of use-case that may be affected: > I want to send logs to a syslog server AND also as a backup to a file on NFS. This means that if the syslog server will be unreachable, it will still be possible to send logs into a backup file on NFS and therefore no logs will be completely lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 11:45:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 11:45:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1008) Elytron Audit Logging does not support logging into more destinations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-1008. ----------------------------------- Fix Version/s: 1.1.0.Beta32 Resolution: Rejected SecurityEventListener.aggregate is available to combine multiple event listeners into one. > Elytron Audit Logging does not support logging into more destinations > --------------------------------------------------------------------- > > Key: ELY-1008 > URL: https://issues.jboss.org/browse/ELY-1008 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta32 > > Attachments: deployment.war > > > According to my understanding it is not possible to send Elytron Audit logs to more destinations (files or syslogs). It is caused by {{security-event-listener}} property within {{security-domain}} takes only _string_ attribute and not _list_ of them. > Example of use-case that may be affected: > I want to send logs to a syslog server AND also as a backup to a file on NFS. This means that if the syslog server will be unreachable, it will still be possible to send logs into a backup file on NFS and therefore no logs will be completely lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 11:55:01 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 16 Mar 2017 11:55:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro reopened WFLY-3858: -------------------------------- Need to reopen, as there was a problem identified with the original fix. > Infinispan cache configuration is not always applied to security-domain > ----------------------------------------------------------------------- > > Key: WFLY-3858 > URL: https://issues.jboss.org/browse/WFLY-3858 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Robert Tuck > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > Attachments: debugger output.txt > > > On Wildfly 8.1.0.Final, I have the following standalone-ha.xml: > > ... > > > > > > > > > ... > > > ... > > > module="deployment.ewb-server-ear.ear"> > > > > > > > > After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries. > After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement: > public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception { > log.debugf("Creating SDC for domain=" + securityDomain); > AuthenticationManager am = createAuthenticationManager(securityDomain); > // create authentication cache > if (cacheFactory instanceof EmbeddedCacheManager) { > EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory); > @SuppressWarnings("rawtypes") > Cache cache = null; > if (cacheManager != null) { > // TODO override global settings with security domain specific > ConfigurationBuilder builder = new ConfigurationBuilder(); > Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache"); > ^^^^ This call here doesn?t always return the correct configuration, baseCfg is then null. > if (baseCfg != null) { > builder.read(baseCfg); > } > cacheManager.defineConfiguration(securityDomain, builder.build()); > cache = cacheManager.getCache(securityDomain); > } > if (cache != null && am instanceof CacheableManager) { > @SuppressWarnings({ "unchecked", "rawtypes" }) > CacheableManager cm = (CacheableManager) am; > cm.setCache(cache); > } > } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) { > > } > getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager: > @Override > public Configuration getCacheConfiguration(String name) { > Configuration configuration = configurationOverrides.get(name); > if (configuration == null && cacheExists(name)) { > return defaultConfiguration; > } > return configuration; > } > Seems like the condition configuration == null occurs when the cache doesn?t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String). > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 12:18:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 16 Mar 2017 12:18:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-73: ------------------------------------- Summary: Rebuild internal cluster 2 Key: HAWKULARQE-73 URL: https://issues.jboss.org/browse/HAWKULARQE-73 Project: Hawkular QE Issue Type: Sub-task Reporter: viet nguyen Assignee: Michael Foley Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - how many pods - verify metrics definition count - verify metrics data -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 12:18:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 16 Mar 2017 12:18:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-73: ------------------------------------- Assignee: viet nguyen (was: Michael Foley) > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - how many pods > - verify metrics definition count > - verify metrics data -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 12:24:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 12:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2550) If Client Cert based authentication is available ensure client auth is requested. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2550: ---------------------------------------- Summary: If Client Cert based authentication is available ensure client auth is requested. Key: WFCORE-2550 URL: https://issues.jboss.org/browse/WFCORE-2550 Project: WildFly Core Issue Type: Bug Components: Remoting, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta10 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 12:26:01 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 16 Mar 2017 12:26:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13379859#comment-13379859 ] RH Bugzilla Integration commented on WFLY-3801: ----------------------------------------------- Radovan Netuka changed the Status of [bug 1136054|https://bugzilla.redhat.com/show_bug.cgi?id=1136054] from NEW to ASSIGNED > Wrong Transaction behaviour for EJBs if JTS is enabled > ------------------------------------------------------ > > Key: WFLY-3801 > URL: https://issues.jboss.org/browse/WFLY-3801 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.1.0.Final > Environment: standalone-full profile with JTS enabled > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log > > > If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation: > WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive > This is only the case if other resources are involved, i.e. a DB via JPA. > If a simple bean is used (like ejb-remote quickstart) this warning is not shown. > It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 12:33:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 12:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8390) Correct RemotingLoginModule test failures. In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8390: -------------------------------------- Summary: Correct RemotingLoginModule test failures. Key: WFLY-8390 URL: https://issues.jboss.org/browse/WFLY-8390 Project: WildFly Issue Type: Bug Components: Security, Test Suite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:33:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1012) Release WildFly Elytron 1.1.0.Beta32 In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1012: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta32 Key: ELY-1012 URL: https://issues.jboss.org/browse/ELY-1012 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta32 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:39:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 16 Mar 2017 13:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, kerberos-security-factory unintentionaly required attribute "options" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFCORE-2549: --------------------------------- Description: *User impact:* User can't configure kerberos authentication in DR14 *Workaround:* There is no workaround *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} But after reload, there is error in server log {code} 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone.xml ----------------------------------- | | 365: | 366: | 367: | ^^^^ 'mappers' isn't an allowed element here | | Elements allowed here are: | audit-logging policy | authentication-client providers | credential-security-factories sasl | credential-stores security-domains | dir-contexts security-properties | http security-realms | mappers tls | | 368: | 369: | 370: | | 'mappers' is allowed in elements: | - server > profile > {urn:wildfly:elytron:1.0}subsystem | " | | The primary underlying error message was: | > ParseError at [row,col]:[367,13] | > Message: WFLYCTL0198: Unexpected element | > '{urn:wildfly:elytron:1.0}mappers' encountered | |------------------------------------------------------------------------------- 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:376) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) at java.lang.Thread.run(Thread.java:745) 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} was: *User impact:* User can't configure kerberos authentication without optional {{options}} attribute *Workaround:* Add any option, even if you don't need any. {code} /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {code} *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} Not setting as alpha blocker, as workaround exists. > Elytron, kerberos-security-factory unintentionaly required attribute "options" > ------------------------------------------------------------------------------ > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication in DR14 > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:40:01 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 16 Mar 2017 13:40:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFCORE-2549: --------------------------------- Summary: Elytron, unable to configure Kerberos authentication (was: Elytron, kerberos-security-factory unintentionaly required attribute "options") > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication in DR14 > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:40:02 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 16 Mar 2017 13:40:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFCORE-2549: --------------------------------- Description: *User impact:* User can't configure kerberos authentication *Workaround:* There is no workaround *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} But after reload, there is error in server log {code} 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone.xml ----------------------------------- | | 365: | 366: | 367: | ^^^^ 'mappers' isn't an allowed element here | | Elements allowed here are: | audit-logging policy | authentication-client providers | credential-security-factories sasl | credential-stores security-domains | dir-contexts security-properties | http security-realms | mappers tls | | 368: | 369: | 370: | | 'mappers' is allowed in elements: | - server > profile > {urn:wildfly:elytron:1.0}subsystem | " | | The primary underlying error message was: | > ParseError at [row,col]:[367,13] | > Message: WFLYCTL0198: Unexpected element | > '{urn:wildfly:elytron:1.0}mappers' encountered | |------------------------------------------------------------------------------- 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:376) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) at java.lang.Thread.run(Thread.java:745) 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} was: *User impact:* User can't configure kerberos authentication in DR14 *Workaround:* There is no workaround *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} But after reload, there is error in server log {code} 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone.xml ----------------------------------- | | 365: | 366: | 367: | ^^^^ 'mappers' isn't an allowed element here | | Elements allowed here are: | audit-logging policy | authentication-client providers | credential-security-factories sasl | credential-stores security-domains | dir-contexts security-properties | http security-realms | mappers tls | | 368: | 369: | 370: | | 'mappers' is allowed in elements: | - server > profile > {urn:wildfly:elytron:1.0}subsystem | " | | The primary underlying error message was: | > ParseError at [row,col]:[367,13] | > Message: WFLYCTL0198: Unexpected element | > '{urn:wildfly:elytron:1.0}mappers' encountered | |------------------------------------------------------------------------------- 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:376) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) at java.lang.Thread.run(Thread.java:745) 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:42:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1012) Release WildFly Elytron 1.1.0.Beta32 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-1012. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta32 > ------------------------------------ > > Key: ELY-1012 > URL: https://issues.jboss.org/browse/ELY-1012 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta32 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:02 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-950) Add local audit log rotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-950: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add local audit log rotation > ---------------------------- > > Key: ELY-950 > URL: https://issues.jboss.org/browse/ELY-950 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Could be by time, size, rotate on start-up or a combination. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:02 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-951) Event handling queues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-951: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Event handling queues > --------------------- > > Key: ELY-951 > URL: https://issues.jboss.org/browse/ELY-951 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Currently audit events are handled synchronously which may be desirable to ensure events are logged. > However this does risk performance so queuing of events may also be desirable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-948) Add additional audit events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-948: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add additional audit events > --------------------------- > > Key: ELY-948 > URL: https://issues.jboss.org/browse/ELY-948 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:02 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-952) Any events send to an AuditEndpoint after it is closed need to raise an error. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-952: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Any events send to an AuditEndpoint after it is closed need to raise an error. > ------------------------------------------------------------------------------ > > Key: ELY-952 > URL: https://issues.jboss.org/browse/ELY-952 > Project: WildFly Elytron > Issue Type: Bug > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Presently events could be dropped. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:02 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-949) Add a mechanism to assign priorities to audit events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-949: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add a mechanism to assign priorities to audit events > ---------------------------------------------------- > > Key: ELY-949 > URL: https://issues.jboss.org/browse/ELY-949 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > We probably want something like MatchRule but also need to think about how it will be configured. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-939) We need to be able to support standard KeyManager instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-939: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > We need to be able to support standard KeyManager instances > ----------------------------------------------------------- > > Key: ELY-939 > URL: https://issues.jboss.org/browse/ELY-939 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > When using PKCS#11 we should not assume we can manipulate the private keys etc.. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within HTTP API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-942: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Review all method names within HTTP API > --------------------------------------- > > Key: ELY-942 > URL: https://issues.jboss.org/browse/ELY-942 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta34 > > > This is a generic HTTP authentication framework not a Servlet authentication framework so should double check the naming is consistent with regards to the HTTP specifications not Servlet. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6 Address Handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-887: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > AuthenticationContext IPv6 Address Handling > ------------------------------------------- > > Key: ELY-887 > URL: https://issues.jboss.org/browse/ELY-887 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta34 > > > Within authentication client we need to ensure we are handling IPv6 addresses correctly. > Especially considering an equivalent IPv6 address can have more than one String representation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication client has no trust configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-937: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > SSLContext in authentication client has no trust configuration > -------------------------------------------------------------- > > Key: ELY-937 > URL: https://issues.jboss.org/browse/ELY-937 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta34 > > > Currently it requires on the system default so it is not possible to configure trusted certificate authorities. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration uniqueness enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-929: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > AuthenticationConfiguration uniqueness enhancements > --------------------------------------------------- > > Key: ELY-929 > URL: https://issues.jboss.org/browse/ELY-929 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta34 > > > Apply some enhancements to AuthenticationConfiguration uniqueness. > * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler > The following also may be possible and useful: > * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}} > * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier}}, or a {{Function References: Message-ID: [ https://issues.jboss.org/browse/ELY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-930: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Support appending a CallbackHandler to the CredentialSources > ------------------------------------------------------------ > > Key: ELY-930 > URL: https://issues.jboss.org/browse/ELY-930 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-722) Move callback handler interactions to a common base class for HTTP mechanisms, . In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-722: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Move callback handler interactions to a common base class for HTTP mechanisms,. > ------------------------------------------------------------------------------- > > Key: ELY-722 > URL: https://issues.jboss.org/browse/ELY-722 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > This is to follow a similar pattern as is used for the SASL mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from generated javadoc. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-681: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Hide private packages from generated javadoc. > --------------------------------------------- > > Key: ELY-681 > URL: https://issues.jboss.org/browse/ELY-681 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > > We may want two profiles so we can generate a full javadoc and a 'public' javadoc. > The 'public' javadoc should be the default one generated and should exclude the following packages: - > org.wildfly.security._private > org.wildfly.security.asn1 > org.wildfly.security.auth.realm > org.wildfly.security.auth.realm.* > org.wildfly.security.authz.jacc > org.wildfly.security.credential.store.impl > org.wildfly.security.security.digest > org.wildfly.security.http.impl > org.wildfly.security.security.keystore > org.wildfly.security.mechanism.oauth2 > org.wildfly.security.mechanism.scram > org.wildfly.security.password.impl > org.wildfly.security.password.util > org.wildfly.security.pem > org.wildfly.security.sasl > org.wildfly.security.sasl.* (Except util) > org.wildfly.security.util > org.wildfly.security.util_private > org.wildfly.security.x500 > org.wildfly.security.x500.cert -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism implementations final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-659: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Make all mechanism implementations final > ---------------------------------------- > > Key: ELY-659 > URL: https://issues.jboss.org/browse/ELY-659 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms, HTTP, SASL > Reporter: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta34 > > > It is very important to make all the mechanism implementations final. Relatedly, they should have no protected members. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in CredentialStore with JDK-8005408 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-926: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > PKCS#12 support in CredentialStore with JDK-8005408 > --------------------------------------------------- > > Key: ELY-926 > URL: https://issues.jboss.org/browse/ELY-926 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Environment: JDK with JDK-8005408 > Reporter: Zoran Regvart > Assignee: Zoran Regvart > Priority: Minor > Fix For: 1.1.0.Beta34 > > > JDK with [JDK-8005408|http://bugs.java.com/view_bug.do?bug_id=8005408] changed the behaviour of PKCS#12 KeyStore so it will use SecretKeyFactory to convert from SecretKeySpec to SecretKey. So a SecretKeyFactorySpi implementation is needed to support PKCS#7 Data OID used when storing data as SecretKeys in the PKCS#12 KeyStore. > This relates to ELY-920 and the test failure on JDK 1.8.0_74. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper implementation. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-889: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add a filtering RoleMapper implementation. > ------------------------------------------ > > Key: ELY-889 > URL: https://issues.jboss.org/browse/ELY-889 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Utils > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > The RoleMapper APIs are built around querying one role at a time, however at times it may be desirable to obtain a set of roles an identity is a member of. > To avoid iterating every role which depending on the configuration could be thousands backed by a remote store we should have a FilteringRoleMapper implementation that will allow any checks and iteration of the roles to be restricted to a finite set of acceptable roles. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication client should not mandate an input source In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-938: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > KeyStore in authentication client should not mandate an input source > -------------------------------------------------------------------- > > Key: ELY-938 > URL: https://issues.jboss.org/browse/ELY-938 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > > Some keystores such as PKCS#11 are initialised without an InputStream. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to be optionally passed a Supplier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-774: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > KeystorePasswordStore needs to be optionally passed a Supplier > -------------------------------------------------------------------------- > > Key: ELY-774 > URL: https://issues.jboss.org/browse/ELY-774 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 1.1.0.Beta34 > > > The current implementation assumes it is globally registered but we may want a configuration without global registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around CredentialSource style storage capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-810: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Unify CredentialStore around CredentialSource style storage capability > ---------------------------------------------------------------------- > > Key: ELY-810 > URL: https://issues.jboss.org/browse/ELY-810 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta34 > > > The following needs to be done: > * Move the PB masked password format to a proper password type > * Introduce protection parameters for credential stores and entries > * Drop the admin_key concept in favor of credential store protection parameters > * Introduce a proper vault-compatible credential store > * Introduce a mechanism to pull protection parameters for stores from the client configuration > * Use a credential store which can store (nearly) any credential type > * Update XML accordingly > * Remove dangerous command execution patterns from credential store, make them safe and make them CredentialSources instead > * Clean up exception hierarchy of credential stores > * Introduce simple map-backed credential store > Additionally, the above implies: > * Introduce AlgorithmParameterSpi for password parameter types > * Introduce hashing ability for parameters > * Add missing parameter types for PBE > * Introduce serialization trickery to support picketbox class names for vault files > * Atomic file output stream > * Update tests as needed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing without jboss-modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-873: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > AuthenticationClient testing without jboss-modules > -------------------------------------------------- > > Key: ELY-873 > URL: https://issues.jboss.org/browse/ELY-873 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Keeping AuthenticationClient usable without a dependency on JBoss Modules is the kind of thing that will be easy to break. > We should probably have a matrix of tests verifying AuthenticationClient anyway, we should then repeat the tests without JBoss Modules on the ClassPath. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:03 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of CLIENT_CERT authentication for SASL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-936: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Complete equivalent of CLIENT_CERT authentication for SASL > ---------------------------------------------------------- > > Key: ELY-936 > URL: https://issues.jboss.org/browse/ELY-936 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta34 > > > This will likely extend outside of Elytron but track it here first. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-849: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Rename setMechanismProperties to setSaslMechanismProperties > ----------------------------------------------------------- > > Key: ELY-849 > URL: https://issues.jboss.org/browse/ELY-849 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta34 > > > If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties. > We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible for "anonymous" identity In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-861: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Role assignment not possible for "anonymous" identity > ----------------------------------------------------- > > Key: ELY-861 > URL: https://issues.jboss.org/browse/ELY-861 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration from SecurityFactory to CredentialSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-822: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Move MechanismConfiguration from SecurityFactory to CredentialSource > -------------------------------------------------------------------------------- > > Key: ELY-822 > URL: https://issues.jboss.org/browse/ELY-822 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > This will make it consistent with client side configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling of isComplete() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-770: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Review SASL mechanism handling of isComplete() > ---------------------------------------------- > > Key: ELY-770 > URL: https://issues.jboss.org/browse/ELY-770 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > > The javadoc of the isComplete() method states: - > _Determines whether the authentication exchange has completed. This method is typically called after each invocation of evaluateResponse() to determine whether the authentication has completed successfully or should be continued._ > Also getAuthorizationID() states: - > _Reports the authorization ID in effect for the client of this session. This method can only be called if isComplete() returns true. > _ > Although the former is very vague there just seem to be a suggestion that complete means successfully complete, our mechs are setting complete very early and other wrappers such as AuthenticationCompleteCallbackSaslServerFactory are using complete as a flag to report failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-486: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages. > ------------------------------------------------------------------------------- > > Key: ELY-486 > URL: https://issues.jboss.org/browse/ELY-486 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing authorization and mechanism information In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-854: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > OAuth2SaslServer is missing authorization and mechanism information > ------------------------------------------------------------------- > > Key: ELY-854 > URL: https://issues.jboss.org/browse/ELY-854 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.1.0.Beta18 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must handle BearerTokenCredential only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-853: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > OAuth2CredentialSource must handle BearerTokenCredential only > ------------------------------------------------------------- > > Key: ELY-853 > URL: https://issues.jboss.org/browse/ELY-853 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.1.0.Beta18 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-765) ServiceLoader Provider and SaslClientFactory discovery should be able to use system ClassLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-765: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > ServiceLoader Provider and SaslClientFactory discovery should be able to use system ClassLoader > ----------------------------------------------------------------------------------------------- > > Key: ELY-765 > URL: https://issues.jboss.org/browse/ELY-765 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Clients may not be running using a JBoss Modules ClassLoader. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is SSLContextAuthenticationConfiguration Still required now sslRules are separated. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-747: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Is SSLContextAuthenticationConfiguration Still required now sslRules are separated. > ----------------------------------------------------------------------------------- > > Key: ELY-747 > URL: https://issues.jboss.org/browse/ELY-747 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering Implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-726: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Default Mechanism Ordering Implementation > ----------------------------------------- > > Key: ELY-726 > URL: https://issues.jboss.org/browse/ELY-726 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > We have to have some form of mechanism ordering anyway to get silent mechanisms to the front of the queue. > SaslMechanismInformation may need some updates but we have plenty of information about the mechanisms so we should be able to put together a reasonable documented ordering. > Stronger mechanisms that can complete without interaction with the client can be pulled up the list as they can quickly silently fail where AuthenticationClient does not have enough information to handle them. This set probably includes JBOSS_LOCAL_USER, EXTERNAL, GSSAPI, GS2, and the token mechs. > For username / password mechanisms we can ensure PLAIN goes last. > Of the CRAM, Digest, and SCRAM set I would suggest first order by digest algorithm and then SCRAM -> Digest -> CRAM. > There will be the opportunity for plenty of discussions on is X really better than Y but I think a reasonable default implementation that is documented will be much better than today's current random ordering. Once filtering has been applied to take into account things like available credentials in the realms etc. > I would expect most lists to be very small, maybe some silent mechs a token mech and one or two username / password mechs depending on consistency of an identity store. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-613: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Some nested classes should be considered to be static nested in Elytron > ----------------------------------------------------------------------- > > Key: ELY-613 > URL: https://issues.jboss.org/browse/ELY-613 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta34 > > > There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered: > * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm > * DecoderState from org.wildfly.security.asn1.DERDecoder > * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm > * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm > * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-728: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. > ------------------------------------------------------------------------------------------ > > Key: ELY-728 > URL: https://issues.jboss.org/browse/ELY-728 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, Realms > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > > This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication should forward authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-559: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Token-based authentication should forward authentication > -------------------------------------------------------- > > Key: ELY-559 > URL: https://issues.jboss.org/browse/ELY-559 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Mechanisms > Reporter: David Lloyd > Fix For: 1.1.0.Beta34 > > > Mechanisms that handle BearerTokenCredetials (ELY-557) should forward them as public or private credentials (ELY-473 / https://github.com/wildfly-security/wildfly-elytron/pull/434 ). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-600) Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-600: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. > --------------------------------------------------------------------------------- > > Key: ELY-600 > URL: https://issues.jboss.org/browse/ELY-600 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-490: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. > ------------------------------------------------------------------------ > > Key: ELY-490 > URL: https://issues.jboss.org/browse/ELY-490 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-639: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > SecurityIdentity and PeerIdentity should have more runAs* variants > ------------------------------------------------------------------ > > Key: ELY-639 > URL: https://issues.jboss.org/browse/ELY-639 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Fix For: 1.1.0.Beta34 > > > The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-595: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded. > ------------------------------------------------------------------------------------------------------ > > Key: ELY-595 > URL: https://issues.jboss.org/browse/ELY-595 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-601: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema > ------------------------------------------------------------------------------------- > > Key: ELY-601 > URL: https://issues.jboss.org/browse/ELY-601 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > > Within the schema a lot of these are configured using 'set'*' elements - switch the methods over to set as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-485) Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-485: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages. > -------------------------------------------------------------------------------- > > Key: ELY-485 > URL: https://issues.jboss.org/browse/ELY-485 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-609: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta34 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-617: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration > --------------------------------------------------------------------------------- > > Key: ELY-617 > URL: https://issues.jboss.org/browse/ELY-617 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Javadoc states various NameRewriter instances will not be null, implementation suggests otherwise. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:05 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-766) It should be possible for domains to be configured with a list of other domains to proactively outflow to. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-766: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > It should be possible for domains to be configured with a list of other domains to proactively outflow to. > ---------------------------------------------------------------------------------------------------------- > > Key: ELY-766 > URL: https://issues.jboss.org/browse/ELY-766 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:04 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-773: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier > ------------------------------------------------------------------------------------------------------------ > > Key: ELY-773 > URL: https://issues.jboss.org/browse/ELY-773 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta34 > > > This may be obsoleted by ongoing work but just wanted an issue to track where AuthenticationConfiguration and related classes currently uses PaswordFactory.getInstance without passing in a Supplier for Provider[]. > * SetCredentialsConfiguration > * SetKeyStoreCredentialAuthenticationConfiguration > * ElytronAuthenticator > * ElytronXmlParser. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-298: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > load-from/uri keystore xsd/parser mismatch > ------------------------------------------ > > Key: ELY-298 > URL: https://issues.jboss.org/browse/ELY-298 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > The xsd has > {code} > > > > > > > > {code} > The parser seems to look for 'uri' rather than 'load-from' -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-181: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Review JACC in Servlet and EJB subsystems > ----------------------------------------- > > Key: ELY-181 > URL: https://issues.jboss.org/browse/ELY-181 > Project: WildFly Elytron > Issue Type: Sub-task > Components: API / SPI > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-455: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > OAuth2 Credential Store > ----------------------- > > Key: ELY-455 > URL: https://issues.jboss.org/browse/ELY-455 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Reporter: David Lloyd > Assignee: Pedro Igor > Fix For: 1.1.0.Beta34 > > > Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-489: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages. > ------------------------------------------------------------------------------ > > Key: ELY-489 > URL: https://issues.jboss.org/browse/ELY-489 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-211: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > Client-side trust store configuration > ------------------------------------- > > Key: ELY-211 > URL: https://issues.jboss.org/browse/ELY-211 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta34 > > > Lest I forget. The client needs the ability to supplement the default trust store, to restrict the set of acceptable peer certificates/signers, for mutual authentication purposes. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:43:06 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-477) XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-477: --------------------------------- Fix Version/s: 1.1.0.Beta34 (was: 1.1.0.Beta32) > XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK > ---------------------------------------------------------- > > Key: ELY-477 > URL: https://issues.jboss.org/browse/ELY-477 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.1.0.Beta4 > Reporter: Ondrej Lukas > Fix For: 1.1.0.Beta34 > > > Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with: > {code} > expected:<-1> but was:<7> > and stacktrace: > java.lang.AssertionError: expected:<-1> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96) > ... > {code} > It is caused by undefined line number of XML parsing failure for IBM JDK. > Stacktrace of checked XMLStreamException for IBM JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} > Stacktrace of checked XMLStreamException for Oracle JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml:7:39: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:47:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 13:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2551) Upgrade to WildFly Core 1.1.0.Beta32 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2551: ---------------------------------------- Summary: Upgrade to WildFly Core 1.1.0.Beta32 Key: WFCORE-2551 URL: https://issues.jboss.org/browse/WFCORE-2551 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta10 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 13:52:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 16 Mar 2017 13:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFCORE-2549: --------------------------------- Description: *User impact:* User can't configure kerberos authentication using Elytron *Workaround:* There is no workaround *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} But after reload, there is error in server log {code} 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone.xml ----------------------------------- | | 365: | 366: | 367: | ^^^^ 'mappers' isn't an allowed element here | | Elements allowed here are: | audit-logging policy | authentication-client providers | credential-security-factories sasl | credential-stores security-domains | dir-contexts security-properties | http security-realms | mappers tls | | 368: | 369: | 370: | | 'mappers' is allowed in elements: | - server > profile > {urn:wildfly:elytron:1.0}subsystem | " | | The primary underlying error message was: | > ParseError at [row,col]:[367,13] | > Message: WFLYCTL0198: Unexpected element | > '{urn:wildfly:elytron:1.0}mappers' encountered | |------------------------------------------------------------------------------- 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:376) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) at java.lang.Thread.run(Thread.java:745) 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} was: *User impact:* User can't configure kerberos authentication *Workaround:* There is no workaround *Description:* If I try command which worked previously I get error {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } {code} In server.log there is this stacktrace {code} 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("kerberos-security-factory" => "a") ]): java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Adding optional {{options}} attribute makes command work again {code} [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) {"outcome" => "success"} {code} But after reload, there is error in server log {code} 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone.xml ----------------------------------- | | 365: | 366: | 367: | ^^^^ 'mappers' isn't an allowed element here | | Elements allowed here are: | audit-logging policy | authentication-client providers | credential-security-factories sasl | credential-stores security-domains | dir-contexts security-properties | http security-realms | mappers tls | | 368: | 369: | 370: | | 'mappers' is allowed in elements: | - server > profile > {urn:wildfly:elytron:1.0}subsystem | " | | The primary underlying error message was: | > ParseError at [row,col]:[367,13] | > Message: WFLYCTL0198: Unexpected element | > '{urn:wildfly:elytron:1.0}mappers' encountered | |------------------------------------------------------------------------------- 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:376) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) at java.lang.Thread.run(Thread.java:745) 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} Attribute {{options}} is marked correctly optional in model. {code} "options" => { "type" => OBJECT, "description" => "The Krb5LoginModule additional options.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => STRING, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:13:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 16 Mar 2017 14:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1481) Validate function signature at compile time and improve error message In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1481: ------------------------------------- Summary: Validate function signature at compile time and improve error message Key: DROOLS-1481 URL: https://issues.jboss.org/browse/DROOLS-1481 Project: Drools Issue Type: Feature Request Components: dmn engine Affects Versions: 7.0.0.Beta7 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final Function signatures as of now are only validated in runtime. We can improve it to add static validation as well. For instance, in the expression: "$"+ (if Payment < 1000 then string(Payment) else (substring(string(Payment),1,1) + "," + substring(string(decimal(Payment,2),2)))) In runtime I get: Unable to find function 'string( class java.math.BigDecimal, class java.math.BigDecimal )' Because of: ...string(decimal(Payment,2),2)... Instead of (see the misplaced parenthesis): ...string(decimal(Payment,2)),2... I think we can also improve the error message to say: Unable to find function 'string( number, number )' -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:14:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 14:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8391) Backport Latest WildFly Elytron Integration Changes In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8391: -------------------------------------- Summary: Backport Latest WildFly Elytron Integration Changes Key: WFLY-8391 URL: https://issues.jboss.org/browse/WFLY-8391 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:16:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 16 Mar 2017 14:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1481) Validate function signature at compile time and improve error message In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1481: ---------------------------------- Description: Function signatures as of now are only validated in runtime. We can improve it to add static validation as well. For instance, in the expression: {code}"$"+ (if Payment < 1000 then string(Payment) else (substring(string(Payment),1,1) + "," + substring(string(decimal(Payment,2),2)))){code} In runtime I get: {quote}Unable to find function 'string( class java.math.BigDecimal, class java.math.BigDecimal )'{quote} Because of: {code}...string(decimal(Payment,2),2)...{code} Instead of (see the misplaced parenthesis): {code}...string(decimal(Payment,2)),2...{code} I think we can also improve the error message to say: {quote}Unable to find function 'string( number, number )'{quote} was: Function signatures as of now are only validated in runtime. We can improve it to add static validation as well. For instance, in the expression: "$"+ (if Payment < 1000 then string(Payment) else (substring(string(Payment),1,1) + "," + substring(string(decimal(Payment,2),2)))) In runtime I get: Unable to find function 'string( class java.math.BigDecimal, class java.math.BigDecimal )' Because of: ...string(decimal(Payment,2),2)... Instead of (see the misplaced parenthesis): ...string(decimal(Payment,2)),2... I think we can also improve the error message to say: Unable to find function 'string( number, number )' > Validate function signature at compile time and improve error message > --------------------------------------------------------------------- > > Key: DROOLS-1481 > URL: https://issues.jboss.org/browse/DROOLS-1481 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > Function signatures as of now are only validated in runtime. We can improve it to add static validation as well. For instance, in the expression: > {code}"$"+ (if Payment < 1000 then string(Payment) else (substring(string(Payment),1,1) + "," + substring(string(decimal(Payment,2),2)))){code} > In runtime I get: > {quote}Unable to find function 'string( class java.math.BigDecimal, class java.math.BigDecimal )'{quote} > Because of: > {code}...string(decimal(Payment,2),2)...{code} > Instead of (see the misplaced parenthesis): > {code}...string(decimal(Payment,2)),2...{code} > I think we can also improve the error message to say: > {quote}Unable to find function 'string( number, number )'{quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:16:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 16 Mar 2017 14:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8131) Aliases in credential stores should be case insensitive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet updated WFLY-8131: ------------------------------------ Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/434, https://github.com/wildfly-security-incubator/wildfly-core/pull/81 (was: https://github.com/wildfly-security/elytron-subsystem/pull/434) > Aliases in credential stores should be case insensitive > ------------------------------------------------------- > > Key: WFLY-8131 > URL: https://issues.jboss.org/browse/WFLY-8131 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store, user_experience > > Working with credential store aliases should be case insensitive. > Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase. > E.g. > {code} > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password) > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove() > {code} > *Current behavior:* > First command succeeds and the second fails as the alias is changed to "upper" (in lowercase). > *Expected behavior:* > Both commans succeeds. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8131 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:19:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 16 Mar 2017 14:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8392) Uninformative description of undertow subsystem configuration for a deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet moved JBEAP-9640 to WFLY-8392: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8392 (was: JBEAP-9640) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Affects Version/s: 10.1.0.Final (was: 7.0.0.GA) > Uninformative description of undertow subsystem configuration for a deployment > ------------------------------------------------------------------------------ > > Key: WFLY-8392 > URL: https://issues.jboss.org/browse/WFLY-8392 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Optional > > The description of undertow subsystem is: {{A deployment}} > Steps to reproduce: > # Deploy an application, e.g. the logging quickstart > # Click Deployments -> deployment name -> View -> expand subsystem -> undertow > Other subsystems have better description, for example logging subsystem: > Information about the logging configuration for this deployment. Note that this may not be accurate if the deployment is using some other means of configuring a log manager such as logback. The resolved configuration is what loggers not covered by the deployments specific log manager would use. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:36:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 16 Mar 2017 14:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2549: ---------------------------------------- Assignee: Brian Stansberry (was: Darran Lofthouse) > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Brian Stansberry > Priority: Blocker > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:38:00 2017 From: issues at jboss.org (Flavia Rainone (JIRA)) Date: Thu, 16 Mar 2017 14:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1337) Support Elytron in security spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavia Rainone resolved JBJCA-1337. ----------------------------------- Resolution: Done > Support Elytron in security spi > ------------------------------- > > Key: JBJCA-1337 > URL: https://issues.jboss.org/browse/JBJCA-1337 > Project: IronJacamar > Issue Type: Feature Request > Components: Core > Environment: Make all adaptations necessary in IronJacamar to support JCA Elytron integration in Wildfly. > Reporter: Flavia Rainone > Assignee: Flavia Rainone > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 14:43:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 16 Mar 2017 14:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) Perform and document a small load test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13379956#comment-13379956 ] viet nguyen commented on HAWKULARQE-47: --------------------------------------- encountered metrics exception. Metrics didn't return https://bugzilla.redhat.com/show_bug.cgi?id=1433061 Set resource limits (CPU, RAM) for metrics and cassandra per developer suggestion and retrying > Perform and document a small load test run > ------------------------------------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:10:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 16 Mar 2017 15:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1482) FEEL: external java function references not working for functions with variable number of parameters In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1482: ------------------------------------- Summary: FEEL: external java function references not working for functions with variable number of parameters Key: DROOLS-1482 URL: https://issues.jboss.org/browse/DROOLS-1482 Project: Drools Issue Type: Feature Request Components: dmn engine Affects Versions: 7.0.0.Beta7 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final External Java functions with variable number of parameters not working. E.g.: {code} { string format : function( mask, value ) external { java : { class : "java.lang.String", method signature : "format( java.lang.String, [Ljava.lang.Object; )" } }, format currency : function( amount ) { string format( "$%,4.2f", amount ) }, result : format currency( 76499.3456 ) } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:16:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 16 Mar 2017 15:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1482) FEEL: external java function references not working for functions with variable number of parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1482: ---------------------------------- Description: External Java functions with variable number of parameters not working. E.g.: {code} { string format : function( mask, value ) external { java : { class : "java.lang.String", method signature : "format( java.lang.String, [Ljava.lang.Object; )" } }, format currency : function( amount ) string format( "$%,4.2f", amount ), result : format currency( 76499.3456 ) } {code} was: External Java functions with variable number of parameters not working. E.g.: {code} { string format : function( mask, value ) external { java : { class : "java.lang.String", method signature : "format( java.lang.String, [Ljava.lang.Object; )" } }, format currency : function( amount ) { string format( "$%,4.2f", amount ) }, result : format currency( 76499.3456 ) } {code} > FEEL: external java function references not working for functions with variable number of parameters > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-1482 > URL: https://issues.jboss.org/browse/DROOLS-1482 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > External Java functions with variable number of parameters not working. E.g.: > {code} > { > string format : function( mask, value ) external { > java : { > class : "java.lang.String", > method signature : "format( java.lang.String, [Ljava.lang.Object; )" > } > }, > format currency : function( amount ) > string format( "$%,4.2f", amount ), > result : format currency( 76499.3456 ) > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:17:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8393) Remove the JACC dependency as it will come from WildFly In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8393: -------------------------------------- Summary: Remove the JACC dependency as it will come from WildFly Key: WFLY-8393 URL: https://issues.jboss.org/browse/WFLY-8393 Project: WildFly Issue Type: Task Components: Build System, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:20:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8393) Remove the JACC dependency as it will come from WildFly Core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8393: ----------------------------------- Summary: Remove the JACC dependency as it will come from WildFly Core (was: Remove the JACC dependency as it will come from WildFly) > Remove the JACC dependency as it will come from WildFly Core > ------------------------------------------------------------ > > Key: WFLY-8393 > URL: https://issues.jboss.org/browse/WFLY-8393 > Project: WildFly > Issue Type: Task > Components: Build System, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:23:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 16 Mar 2017 15:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2552) Swapped descriptions of Remoting subsystem attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9642 to WFCORE-2552: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2552 (was: JBEAP-9642) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting (was: Remoting) (was: User Experience) Affects Version/s: (was: 7.1.0.DR7) > Swapped descriptions of Remoting subsystem attributes > ----------------------------------------------------- > > Key: WFCORE-2552 > URL: https://issues.jboss.org/browse/WFCORE-2552 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Jan Martiska > Assignee: David Lloyd > > The description (in management model *AND* the XSD file!) for {{max-outbound-messages}} is > bq. The maximum number of outbound channels to support for a connection. > and for {{max-inbound-messages}} > bq. The maximum number of inbound channels to support for a connection. > for {{max-outbound-channels}}: > bq. The maximum number of concurrent outbound messages on a channel. > for {{max-inbound-channels}}: > bq. The maximum number of concurrent inbound messages on a channel. > I guess these descriptions should be the other way around, they confuse channels and messages :) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:23:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 16 Mar 2017 15:23:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2552) Swapped descriptions of Remoting subsystem attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2552: ---------------------------------------- Assignee: Brian Stansberry (was: David Lloyd) > Swapped descriptions of Remoting subsystem attributes > ----------------------------------------------------- > > Key: WFCORE-2552 > URL: https://issues.jboss.org/browse/WFCORE-2552 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Jan Martiska > Assignee: Brian Stansberry > > The description (in management model *AND* the XSD file!) for {{max-outbound-messages}} is > bq. The maximum number of outbound channels to support for a connection. > and for {{max-inbound-messages}} > bq. The maximum number of inbound channels to support for a connection. > for {{max-outbound-channels}}: > bq. The maximum number of concurrent outbound messages on a channel. > for {{max-inbound-channels}}: > bq. The maximum number of concurrent inbound messages on a channel. > I guess these descriptions should be the other way around, they confuse channels and messages :) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:41:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 16 Mar 2017 15:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5806) IllegalStateException during deployment of HA Singleton deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro reopened WFLY-5806: -------------------------------- > IllegalStateException during deployment of HA Singleton deployment > ------------------------------------------------------------------ > > Key: WFLY-5806 > URL: https://issues.jboss.org/browse/WFLY-5806 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Minor > Fix For: 10.0.0.CR5 > > > Seen in failover tests - HA Singleton deployment scenarios - no matter what failover type was used (graceful shutdown, jvmkill, undeploy). > When the node is elected to operate as the singleton provider, sometimes this INFO message is logged: > {code} > INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-singleton-jbossall.ear, performing full redeploy instead. > {code} > Then the redeploy will fail: > {code} > [JBossINF] [0m[33m05:41:07,118 WARN [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-web-passivating.war".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > Then these events follows: > - This node will no longer operate as the singleton provider > - immediately after that the node is re-elected as the singleton provider and the deployment starts successfully > See the full stacktrace: > {code} > [JBossINF] [0m[0m05:41:07,109 INFO [org.wildfly.clustering.server] (OOB-19,ee,perf19) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service > [JBossINF] [0m[0m05:41:07,112 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-singleton-jbossall.ear, performing full redeploy instead. > [JBossINF] [0m[0m05:41:07,114 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-web-passivating.war, performing full redeploy instead. > [JBossINF] [0m[0m05:41:07,114 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-ejb.jar, performing full redeploy instead. > [JBossINF] [0m[0m05:41:07,114 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-web-default.war, performing full redeploy instead. > [JBossINF] [0m[33m05:41:07,118 WARN [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-web-passivating.war".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] [0m[33m05:41:07,117 WARN [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-web-default.war".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] [0m[33m05:41:07,116 WARN [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-ejb.jar".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] [0m[0m05:41:07,150 INFO [org.wildfly.clustering.server] (OOB-19,ee,perf19) WFLYCLSV0002: This node will no longer operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service > [JBossINF] [0m[0m05:41:07,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel hibernate > [JBossINF] [0m[0m05:41:07,171 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel hibernate > [JBossINF] [0m[0m05:41:07,171 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel web > [JBossINF] [0m[0m05:41:07,172 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web > [JBossINF] [0m[0m05:41:07,172 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 58ms > [JBossINF] [0m[0m05:41:07,173 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb > [JBossINF] [0m[0m05:41:07,173 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb > [JBossINF] [0m[0m05:41:07,176 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 62ms > [JBossINF] [0m[0m05:41:07,175 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 61ms > [JBossINF] [0m[0m05:41:07,184 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment clusterbench-ee7-singleton-jbossall.ear (runtime-name: clusterbench-ee7-singleton-jbossall.ear) in 70ms > [JBossINF] [0m[0m05:41:07,186 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "clusterbench-ee7-singleton-jbossall.ear" (runtime-name: "clusterbench-ee7-singleton-jbossall.ear") > [JBossINF] [0m[0m05:41:07,187 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 82) WFLYCLINF0003: Stopped default cache from server container > [JBossINF] [0m[0m05:41:07,190 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel server > [JBossINF] [0m[0m05:41:07,190 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel server > [JBossINF] [0m[0m05:41:07,232 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-passivating.war") > [JBossINF] [0m[0m05:41:07,232 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-default.war") > [JBossINF] [0m[0m05:41:07,232 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-ejb.jar") > [JBossINF] [0m[33m05:41:07,294 WARN [org.jboss.as.dependency.private] (MSC service thread 1-8) WFLYSRV0018: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-default.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[33m05:41:07,295 WARN [org.jboss.as.dependency.unsupported] (MSC service thread 1-8) WFLYSRV0019: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-default.war" is using an unsupported module ("org.jgroups:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[33m05:41:07,295 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-passivating.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[33m05:41:07,295 WARN [org.jboss.as.dependency.unsupported] (MSC service thread 1-1) WFLYSRV0019: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-passivating.war" is using an unsupported module ("org.jgroups:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[0m05:41:07,423 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000078: Starting JGroups channel server > [JBossINF] [0m[0m05:41:07,424 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel server: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,424 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000079: Channel server local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,426 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel web > [JBossINF] [0m[0m05:41:07,427 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel web: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,427 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079: Channel web local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,442 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb > [JBossINF] [0m[0m05:41:07,444 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,444 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,444 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel hibernate > [JBossINF] [0m[0m05:41:07,445 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel hibernate: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,446 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel hibernate local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,510 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 82) WFLYCLINF0002: Started default cache from server container > [JBossINF] [0m[0m05:41:10,357 INFO [org.wildfly.clustering.server] (OOB-20,ee,perf19) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service > [JBossINF] [0m[0m05:41:10,362 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment clusterbench-ee7-singleton-jbossall.ear > [JBossINF] [0m[0m05:41:10,384 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment clusterbench-ee7-ejb.jar > [JBossINF] [0m[0m05:41:10,387 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'RemoteStatelessSBImpl' in deployment unit 'subdeployment "clusterbench-ee7-ejb.jar" of deployment "clusterbench-ee7-singleton-jbossall.ear"' are as follows: > [JBossINF] > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:module/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:jboss/exported/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatelessSBImpl > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatelessSBImpl > [JBossINF] java:module/RemoteStatelessSBImpl > [JBossINF] > [JBossINF] [0m[0m05:41:10,387 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'RemoteStatefulSBImpl' in deployment unit 'subdeployment "clusterbench-ee7-ejb.jar" of deployment "clusterbench-ee7-singleton-jbossall.ear"' are as follows: > [JBossINF] > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:module/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:jboss/exported/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatefulSBImpl > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatefulSBImpl > [JBossINF] java:module/RemoteStatefulSBImpl > [JBossINF] > [JBossINF] [0m[0m05:41:10,387 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'LocalStatefulSB' in deployment unit 'subdeployment "clusterbench-ee7-ejb.jar" of deployment "clusterbench-ee7-singleton-jbossall.ear"' are as follows: > [JBossINF] > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/LocalStatefulSB!org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB > [JBossINF] java:app/clusterbench-ee7-ejb/LocalStatefulSB!org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB > [JBossINF] java:module/LocalStatefulSB!org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/LocalStatefulSB > [JBossINF] java:app/clusterbench-ee7-ejb/LocalStatefulSB > [JBossINF] java:module/LocalStatefulSB > [JBossINF] > {code} > Link: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-singleton-deployment-jvmkill-random-election-policy/5/console-perf19/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:45:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2461) Credential-store attribute relative-to doesn't reference path as required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2461: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Credential-store attribute relative-to doesn't reference path as required > ------------------------------------------------------------------------- > > Key: WFCORE-2461 > URL: https://issues.jboss.org/browse/WFCORE-2461 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ilia Vassilev > Fix For: 3.0.0.Beta10 > > > Combination of {{path}} and {{relative-to}} attributes is common across all the elytron subsystem. All but one {{relative-to}} attributes list the "path" as required: > {code} > "relative-to" => { > "type" => STRING, > ... > "requires" => ["path"], > ... > } > {code} > The credential-store configuration doesn't define this dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:47:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2425) Allow expressions in credential-reference attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2425: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Allow expressions in credential-reference attributes > ---------------------------------------------------- > > Key: WFCORE-2425 > URL: https://issues.jboss.org/browse/WFCORE-2425 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: user_experience > Fix For: 3.0.0.Beta10 > > > Change these attributes to {{"expressions-allowed" => true}} > {code} > These applies to key-store and key-manager: > */credential-reference/alias > */credential-reference/type > */credential-reference/clear-text > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:47:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 16 Mar 2017 15:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-53) Validation queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13379989#comment-13379989 ] viet nguyen commented on HAWKULARQE-53: --------------------------------------- duplicate of HAWKULARQE-47 > Validation queries > ------------------ > > Key: HAWKULARQE-53 > URL: https://issues.jboss.org/browse/HAWKULARQE-53 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Create some sort of report to show metrics generated by HOSA -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:48:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 16 Mar 2017 15:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-53) Validation queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen closed HAWKULARQE-53. --------------------------------- Resolution: Done > Validation queries > ------------------ > > Key: HAWKULARQE-53 > URL: https://issues.jboss.org/browse/HAWKULARQE-53 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Create some sort of report to show metrics generated by HOSA -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:48:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2500) Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2500: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2500 > URL: https://issues.jboss.org/browse/WFCORE-2500 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Tomas Hofman > Fix For: 3.0.0.Beta10 > > > Changing attribute changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state even though header allow-resource-service-restart=true is used > {code} > [standalone at localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true} > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Header should work as attribute is declared as {{"restart-required" => "resource-services"}} > {code} > "http-server-mechanism-factory" => { > "type" => STRING, > "description" => "The HttpServerAuthenticationMechanismFactory to associate with this resource", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "capability-reference" => "org.wildfly.security.http-server-mechanism-factory", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > {code} > And according to documentation [1]: > resource-services ? The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.) > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:49:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2542) Upgrade wildfly-discovery to 1.0.0.Beta10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2542: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Upgrade wildfly-discovery to 1.0.0.Beta10 > ----------------------------------------- > > Key: WFCORE-2542 > URL: https://issues.jboss.org/browse/WFCORE-2542 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 3.0.0.Beta10 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:53:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8331) Fix deployment overlay tests to not hide authentication problems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8331: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Fix deployment overlay tests to not hide authentication problems > ---------------------------------------------------------------- > > Key: WFLY-8331 > URL: https://issues.jboss.org/browse/WFLY-8331 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Fix For: 11.0.0.Alpha1 > > > The deployment overlay tests in {{testsuite/integration/basic}} module have to be updated. The current implementation hide problems which occur before adding the overlay (as there is another failure in {{finally}} section. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 15:56:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 15:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8382) Elytron, unable to create custom principal transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8382: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Elytron, unable to create custom principal transformer > ------------------------------------------------------ > > Key: WFLY-8382 > URL: https://issues.jboss.org/browse/WFLY-8382 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > When I try to register custom principal transformer I get {{NoClassDefFoundError}} > {code} > 07:11:37,203 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.mapper.AddCustomPrincipalTransformerImpl in Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 07:11:37,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module "org.jboss.customprincipaltransformerimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 07:11:37,207 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-principal-transformer" => "CreaperTestAddCustomPrincipalTransformer") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer" => "org.jboss.msc.service.StartException in service org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/mapper/AddCustomPrincipalTransformerImpl (Module \"org.jboss.customprincipaltransformerimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules,/home/mchoma/workspace/git-repositories/creaper/testsuite/standalone/target/jboss-as/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/PrincipalTransformer"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.principal-transformer.CreaperTestAddCustomPrincipalTransformer"] > } > {code} > That works in DR11 without issue > Here is implementation of used custom prncipal transformer > {code:java|title=AddCustomPrincipalTransformerImpl.java} > package org.wildfly.extras.creaper.commands.elytron.mapper; > import org.wildfly.extension.elytron.Configurable; > import java.security.Principal; > import java.util.Map; > import org.wildfly.extension.elytron.capabilities.PrincipalTransformer; > public class AddCustomPrincipalTransformerImpl implements PrincipalTransformer, Configurable { > @Override > public Principal apply(Principal p) { > return p; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 16:12:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 16 Mar 2017 16:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5806) IllegalStateException during failover of HA Singleton deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-5806: ------------------------------- Summary: IllegalStateException during failover of HA Singleton deployment (was: IllegalStateException during deployment of HA Singleton deployment) > IllegalStateException during failover of HA Singleton deployment > ---------------------------------------------------------------- > > Key: WFLY-5806 > URL: https://issues.jboss.org/browse/WFLY-5806 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Minor > Fix For: 10.0.0.CR5 > > > Seen in failover tests - HA Singleton deployment scenarios - no matter what failover type was used (graceful shutdown, jvmkill, undeploy). > When the node is elected to operate as the singleton provider, sometimes this INFO message is logged: > {code} > INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-singleton-jbossall.ear, performing full redeploy instead. > {code} > Then the redeploy will fail: > {code} > [JBossINF] [0m[33m05:41:07,118 WARN [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-web-passivating.war".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > Then these events follows: > - This node will no longer operate as the singleton provider > - immediately after that the node is re-elected as the singleton provider and the deployment starts successfully > See the full stacktrace: > {code} > [JBossINF] [0m[0m05:41:07,109 INFO [org.wildfly.clustering.server] (OOB-19,ee,perf19) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service > [JBossINF] [0m[0m05:41:07,112 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-singleton-jbossall.ear, performing full redeploy instead. > [JBossINF] [0m[0m05:41:07,114 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-web-passivating.war, performing full redeploy instead. > [JBossINF] [0m[0m05:41:07,114 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-ejb.jar, performing full redeploy instead. > [JBossINF] [0m[0m05:41:07,114 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0070: Deployment restart detected for deployment clusterbench-ee7-web-default.war, performing full redeploy instead. > [JBossINF] [0m[33m05:41:07,118 WARN [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-web-passivating.war".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] [0m[33m05:41:07,117 WARN [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-web-default.war".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] [0m[33m05:41:07,116 WARN [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-ejb.jar".FIRST_MODULE_USE.service: java.lang.IllegalStateException > [JBossINF] at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:225) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > [JBossINF] > [JBossINF] [0m[0m05:41:07,150 INFO [org.wildfly.clustering.server] (OOB-19,ee,perf19) WFLYCLSV0002: This node will no longer operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service > [JBossINF] [0m[0m05:41:07,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel hibernate > [JBossINF] [0m[0m05:41:07,171 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel hibernate > [JBossINF] [0m[0m05:41:07,171 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel web > [JBossINF] [0m[0m05:41:07,172 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web > [JBossINF] [0m[0m05:41:07,172 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 58ms > [JBossINF] [0m[0m05:41:07,173 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb > [JBossINF] [0m[0m05:41:07,173 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb > [JBossINF] [0m[0m05:41:07,176 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 62ms > [JBossINF] [0m[0m05:41:07,175 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 61ms > [JBossINF] [0m[0m05:41:07,184 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment clusterbench-ee7-singleton-jbossall.ear (runtime-name: clusterbench-ee7-singleton-jbossall.ear) in 70ms > [JBossINF] [0m[0m05:41:07,186 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "clusterbench-ee7-singleton-jbossall.ear" (runtime-name: "clusterbench-ee7-singleton-jbossall.ear") > [JBossINF] [0m[0m05:41:07,187 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 82) WFLYCLINF0003: Stopped default cache from server container > [JBossINF] [0m[0m05:41:07,190 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel server > [JBossINF] [0m[0m05:41:07,190 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel server > [JBossINF] [0m[0m05:41:07,232 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-passivating.war") > [JBossINF] [0m[0m05:41:07,232 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-default.war") > [JBossINF] [0m[0m05:41:07,232 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-ejb.jar") > [JBossINF] [0m[33m05:41:07,294 WARN [org.jboss.as.dependency.private] (MSC service thread 1-8) WFLYSRV0018: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-default.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[33m05:41:07,295 WARN [org.jboss.as.dependency.unsupported] (MSC service thread 1-8) WFLYSRV0019: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-default.war" is using an unsupported module ("org.jgroups:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[33m05:41:07,295 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-passivating.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[33m05:41:07,295 WARN [org.jboss.as.dependency.unsupported] (MSC service thread 1-1) WFLYSRV0019: Deployment "deployment.clusterbench-ee7-singleton-jbossall.ear.clusterbench-ee7-web-passivating.war" is using an unsupported module ("org.jgroups:main") which may be changed or removed in future versions without notice. > [JBossINF] [0m[0m05:41:07,423 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000078: Starting JGroups channel server > [JBossINF] [0m[0m05:41:07,424 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel server: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,424 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000079: Channel server local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,426 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel web > [JBossINF] [0m[0m05:41:07,427 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel web: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,427 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079: Channel web local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,442 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb > [JBossINF] [0m[0m05:41:07,444 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,444 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,444 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel hibernate > [JBossINF] [0m[0m05:41:07,445 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel hibernate: [perf21|13] (4) [perf21, perf18, perf20, perf19] > [JBossINF] [0m[0m05:41:07,446 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel hibernate local address is perf19, physical addresses are [172.19.1.3:55200] > [JBossINF] [0m[0m05:41:07,510 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 82) WFLYCLINF0002: Started default cache from server container > [JBossINF] [0m[0m05:41:10,357 INFO [org.wildfly.clustering.server] (OOB-20,ee,perf19) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service > [JBossINF] [0m[0m05:41:10,362 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment clusterbench-ee7-singleton-jbossall.ear > [JBossINF] [0m[0m05:41:10,384 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment clusterbench-ee7-ejb.jar > [JBossINF] [0m[0m05:41:10,387 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'RemoteStatelessSBImpl' in deployment unit 'subdeployment "clusterbench-ee7-ejb.jar" of deployment "clusterbench-ee7-singleton-jbossall.ear"' are as follows: > [JBossINF] > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:module/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:jboss/exported/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatelessSBImpl!org.jboss.test.clusterbench.ejb.stateless.RemoteStatelessSB > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatelessSBImpl > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatelessSBImpl > [JBossINF] java:module/RemoteStatelessSBImpl > [JBossINF] > [JBossINF] [0m[0m05:41:10,387 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'RemoteStatefulSBImpl' in deployment unit 'subdeployment "clusterbench-ee7-ejb.jar" of deployment "clusterbench-ee7-singleton-jbossall.ear"' are as follows: > [JBossINF] > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:module/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:jboss/exported/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/RemoteStatefulSBImpl > [JBossINF] java:app/clusterbench-ee7-ejb/RemoteStatefulSBImpl > [JBossINF] java:module/RemoteStatefulSBImpl > [JBossINF] > [JBossINF] [0m[0m05:41:10,387 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'LocalStatefulSB' in deployment unit 'subdeployment "clusterbench-ee7-ejb.jar" of deployment "clusterbench-ee7-singleton-jbossall.ear"' are as follows: > [JBossINF] > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/LocalStatefulSB!org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB > [JBossINF] java:app/clusterbench-ee7-ejb/LocalStatefulSB!org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB > [JBossINF] java:module/LocalStatefulSB!org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB > [JBossINF] java:global/clusterbench-ee7-singleton-jbossall/clusterbench-ee7-ejb/LocalStatefulSB > [JBossINF] java:app/clusterbench-ee7-ejb/LocalStatefulSB > [JBossINF] java:module/LocalStatefulSB > [JBossINF] > {code} > Link: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-singleton-deployment-jvmkill-random-election-policy/5/console-perf19/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 16:17:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 16:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2549: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Brian Stansberry > Priority: Blocker > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 16:17:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 16:17:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2549: ------------------------------------- Fix Version/s: (was: 3.0.0.Beta10) > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Brian Stansberry > Priority: Blocker > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 17:04:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 16 Mar 2017 17:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) Perform and document a small load test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380013#comment-13380013 ] viet nguyen commented on HAWKULARQE-47: --------------------------------------- Testing notes: https://gist.github.com/vnugent/0b1fb80c14d4c95ddf527318a57fdb80 > Perform and document a small load test run > ------------------------------------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 17:47:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 17:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated SECURITY-921: -------------------------------------- Fix Version/s: Negotiation_3_0_4_CR1 > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > Fix For: Negotiation_3_0_4_CR1 > > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 18:41:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 16 Mar 2017 18:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1962) Avoid deprecated api usage in jgroups and infinispan subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro closed WFLY-1962. ------------------------------ Resolution: Out of Date > Avoid deprecated api usage in jgroups and infinispan subsystems > --------------------------------------------------------------- > > Key: WFLY-1962 > URL: https://issues.jboss.org/browse/WFLY-1962 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Minor > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 18:45:01 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 16 Mar 2017 18:45:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8394) Deprecate binary-keyed-jdbc-store and mixed-keyed-jdbc-store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9647 to WFLY-8394: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8394 (was: JBEAP-9647) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) > Deprecate binary-keyed-jdbc-store and mixed-keyed-jdbc-store > ------------------------------------------------------------ > > Key: WFLY-8394 > URL: https://issues.jboss.org/browse/WFLY-8394 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > These implementations are inefficient and are being removed without replacement in Infinispan 9.0. > As string-keyed-jdbc-store will be the only remaining implementation, we can rename this to jdbc-store. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:04:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated SECURITY-921: -------------------------------------- Fix Version/s: Negotiation_2_3_13_Final > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > Fix For: Negotiation_3_0_4_Final, Negotiation_2_3_13_Final > > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:04:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:04:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SECURITY-921. --------------------------------------- Resolution: Done > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > Fix For: Negotiation_3_0_4_Final, Negotiation_2_3_13_Final > > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:08:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-964) Release JBoss Negotiation 3.0.4.Final In-Reply-To: References: Message-ID: Darran Lofthouse created SECURITY-964: ----------------------------------------- Summary: Release JBoss Negotiation 3.0.4.Final Key: SECURITY-964 URL: https://issues.jboss.org/browse/SECURITY-964 Project: PicketBox Issue Type: Release Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_3_0_4_Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:14:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-964) Release JBoss Negotiation 3.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SECURITY-964. --------------------------------------- Resolution: Done > Release JBoss Negotiation 3.0.4.Final > ------------------------------------- > > Key: SECURITY-964 > URL: https://issues.jboss.org/browse/SECURITY-964 > Project: PicketBox > Issue Type: Release > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_4_Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-915) Migrate MessageFactory discovery to use ServiceLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated SECURITY-915: -------------------------------------- Fix Version/s: Negotiation_3_0_5_CR1 (was: Negotiation_3_0_4_Final) > Migrate MessageFactory discovery to use ServiceLoader > ----------------------------------------------------- > > Key: SECURITY-915 > URL: https://issues.jboss.org/browse/SECURITY-915 > Project: PicketBox > Issue Type: Feature Request > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_5_CR1 > > > At the moment we have statically defined class names and attempt to load them in turn to identify which ones are actually available - ServiceLoader based discovery would eliminate this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-917) Remove setStatusCode call in NegotiationMechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated SECURITY-917: -------------------------------------- Fix Version/s: Negotiation_3_0_5_CR1 (was: Negotiation_3_0_4_Final) > Remove setStatusCode call in NegotiationMechanism > ------------------------------------------------- > > Key: SECURITY-917 > URL: https://issues.jboss.org/browse/SECURITY-917 > Project: PicketBox > Issue Type: Task > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_5_CR1 > > > Once UNDERTOW-548 is resolved we can remove manually setting the status code ourselves. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-943) AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated SECURITY-943: -------------------------------------- Fix Version/s: Negotiation_3_0_5_CR1 (was: Negotiation_3_0_4_Final) > AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL > ------------------------------------------------------------------------------------- > > Key: SECURITY-943 > URL: https://issues.jboss.org/browse/SECURITY-943 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_2_Final > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_5_CR1 > > > In case when part of DN is placed in LDAP URL instead of baseCtxDN then authentication fails (see [1] for details about this URL) in AdvancedLdapLoginModule. Authentication is provided by binding with user DN and password, but in this case user DN does not include DN part from LDAP URL which leads to fail. > Thrown exception: > {code} > javax.naming.AuthenticationException: LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=jduke,ou=People > com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3135) > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3081) > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2883) > com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2797) > com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:319) > com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114) > org.jboss.as.naming.InitialContext.init(InitialContext.java:99) > javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:154) > org.jboss.as.naming.InitialContext.(InitialContext.java:89) > org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43) > javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > javax.naming.InitialContext.init(InitialContext.java:244) > javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:154) > org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:486) > org.jboss.security.negotiation.AdvancedLdapLoginModule.authenticate(AdvancedLdapLoginModule.java:669) > org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:397) > org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:967) > org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:326) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > {code} > [1] https://tools.ietf.org/html/rfc2255 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-965) Release JBoss Negotiation 2.3.13.Final In-Reply-To: References: Message-ID: Darran Lofthouse created SECURITY-965: ----------------------------------------- Summary: Release JBoss Negotiation 2.3.13.Final Key: SECURITY-965 URL: https://issues.jboss.org/browse/SECURITY-965 Project: PicketBox Issue Type: Release Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_3_13_Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:22:00 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Thu, 16 Mar 2017 19:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1013) PBE utility needs PicketBox compatible mode In-Reply-To: References: Message-ID: Peter Skopek created ELY-1013: --------------------------------- Summary: PBE utility needs PicketBox compatible mode Key: ELY-1013 URL: https://issues.jboss.org/browse/ELY-1013 Project: WildFly Elytron Issue Type: Enhancement Components: Utils Affects Versions: 1.1.0.Beta32 Reporter: Peter Skopek Assignee: Peter Skopek To fix issue https://issues.jboss.org/browse/WFCORE-2421 we need to have PicketBox compatibility mode in PBE utility class. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:24:00 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Thu, 16 Mar 2017 19:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1013) PicketBox compatibility mode for PBE utility In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Skopek updated ELY-1013: ------------------------------ Summary: PicketBox compatibility mode for PBE utility (was: PBE utility needs PicketBox compatible mode) > PicketBox compatibility mode for PBE utility > -------------------------------------------- > > Key: ELY-1013 > URL: https://issues.jboss.org/browse/ELY-1013 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Utils > Affects Versions: 1.1.0.Beta32 > Reporter: Peter Skopek > Assignee: Peter Skopek > > To fix issue https://issues.jboss.org/browse/WFCORE-2421 we need to have PicketBox compatibility mode in PBE utility class. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:28:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:28:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8395) Upgrade jboss-negotiation to 3.0.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved JBEAP-9648 to WFLY-8395: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8395 (was: JBEAP-9648) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > Upgrade jboss-negotiation to 3.0.4 > ---------------------------------- > > Key: WFLY-8395 > URL: https://issues.jboss.org/browse/WFLY-8395 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: legacy > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:36:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 16 Mar 2017 19:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-965) Release JBoss Negotiation 2.3.13.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SECURITY-965. --------------------------------------- Resolution: Done > Release JBoss Negotiation 2.3.13.Final > -------------------------------------- > > Key: SECURITY-965 > URL: https://issues.jboss.org/browse/SECURITY-965 > Project: PicketBox > Issue Type: Release > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_13_Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:49:01 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 19:49:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-1758. --------------------------------- Resolution: Out of Date I'm not seeing this issue any longer. If you're still seeing it on the newest versions of maven plugin please feel free to reopen. > WFLYCC0034: Closing leaked controller client > -------------------------------------------- > > Key: WFCORE-1758 > URL: https://issues.jboss.org/browse/WFCORE-1758 > Project: WildFly Core > Issue Type: Bug > Reporter: Martin Choma > Assignee: James Perkins > Attachments: server.log > > > We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method. > I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ? > *Reproducer:* > 1. using ibm java 1.8 > 2. setting 1 > [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src/main/java/org/jboss/as/controller/client/impl/RemotingModelControllerClient.java#L147 > [2] https://www.youtube.com/watch?v=UrGP6pfb0H8 > [3] > {noformat} > 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize > 05:54:10 WARN: WFLYCC0034: Closing leaked controller client > 05:54:10 WFLYCC0030: Allocation stack trace: > 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552) > 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.(RemotingModelControllerClient.java:74) > 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567) > 05:54:10 at org.wildfly.plugin.common.ManagementClient.(ManagementClient.java:37) > 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126) > 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269) > 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) > 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498) > 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:53:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 19:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1548) Access denied when deploying to wildfly 10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-1548. --------------------------------- Resolution: Rejected I'm closing this as rejected because it does seem it's related to an antivirus scan. > Access denied when deploying to wildfly 10 > ------------------------------------------ > > Key: WFCORE-1548 > URL: https://issues.jboss.org/browse/WFCORE-1548 > Project: WildFly Core > Issue Type: Bug > Environment: Wildfly 10, Windows 7, java 1.8_05, maven 3.0.5, maven 3.3.9 > Reporter: Srecko Mandelj > Assignee: James Perkins > Priority: Minor > Attachments: TestMavenPlugin.zip, server.log > > > I have a war application containing web services. I have no problems deploying war to wildfly 8.1. After upgrade to wildfly 10, the plugin doesn't work any more. I get this error when trying to deploy: > {code} > [Server:server-one] 09:36:51,162 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 132) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/ActivatorFrontEnd' > [Server:server-one] 09:36:51,220 SEVERE [javax.enterprise.resource.webcontainer. > jsf.config] (ServerService Thread Pool -- 132) Critical error during deployment: > : com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: javax.faces.FacesException: java.io.FileNotFoundException: C:\podatki\jboss_configurations\wildfly10\domainController\servers\server-one\tmp\vfs\temp\temp1e3a1daf9121b0e4\content-34b685741ee5aeb4\content-6322725066713898564.tmp (Access is denied) > {code} > It looks like a concurrency issue - one process is trying to use a file that other process is using. If I deploy through web console or via CLI, I don't have this issue. It is somehow related to jsf implementation. If I remove jsf from wildfly configuration file (the module and subsystem), deploy works ok (Mojara is then not triggered and deploy is successful). > I tried to deploy with 1.1.9.Alpha8, but I get the same error. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:54:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 19:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-682) Review usage of hard-coded string constants with the application server name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-682. -------------------------------- Resolution: Rejected > Review usage of hard-coded string constants with the application server name > ---------------------------------------------------------------------------- > > Key: WFCORE-682 > URL: https://issues.jboss.org/browse/WFCORE-682 > Project: WildFly Core > Issue Type: Task > Reporter: James Perkins > Assignee: James Perkins > > This is meant to be a parent for all smaller issues that might creep up with hard-coded string constants for the application server name. For example if a message in a message bundle has {{WidFly Core 1.0.0..xxx started in...}} we need to ensure the server name is a variable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:56:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 19:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-479) The testFormats() tests in the HandlerOperationsTestCase needs to ensure colors are being used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-479. -------------------------------- Resolution: Rejected > The testFormats() tests in the HandlerOperationsTestCase needs to ensure colors are being used > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-479 > URL: https://issues.jboss.org/browse/WFCORE-479 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > In environments like Windows colored log output is not turned on by default. The test needs to take this into account and not assume that colored output will be printed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 19:59:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 19:59:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-454) Rewrite the logging.properties file if the jboss.server.log.dir property is changed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-454. -------------------------------- Resolution: Done This won't be relevant when WFCORE-157 is solved. > Rewrite the logging.properties file if the jboss.server.log.dir property is changed > ----------------------------------------------------------------------------------- > > Key: WFCORE-454 > URL: https://issues.jboss.org/browse/WFCORE-454 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The {{PathManager}} has a way to handle callbacks when the value of a path property is changed. The logging subsystem should add a callback to change the paths (possibly not at runtime??) and rewrite the logging.properties file with the new fully qualified path. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 20:00:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 20:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-249) Wrap the default logging handlers in an AsyncHandler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-249. -------------------------------- Resolution: Rejected I don't see much benefit in this. If anyone disagrees please feel free to reopen. > Wrap the default logging handlers in an AsyncHandler > ---------------------------------------------------- > > Key: WFCORE-249 > URL: https://issues.jboss.org/browse/WFCORE-249 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > > This change could potentially enhance performance under heavier logging loads, but the the disadvantages probably need to be considered first. > * Under light logging load, is performance improved much? > * How about under medium load? > * Under heavy load, the async queue may overflow, causing either one of two sceanrios: > ** {{OverflowAction.DISCARD}}: The loss of messages. Probably not the right choice for default. > ** {{OverflowAction.BLOCK}}: Threads block until queue clears. Could be argued that async is not much better than plain synchronous logging in this scenario. > * If the aync thread crashes, are messages lost? If so, is this much worse than synchronous logging, and how often can an async thread crash? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 20:01:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 20:01:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-245. -------------------------------- Resolution: Out of Date I believe this is out of date. If not please feel free to reopen. > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 20:13:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 20:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-40) Deadlock while logging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-40. ------------------------------- Resolution: Out of Date If this is still an issue please feel free to reopen. > Deadlock while logging > ---------------------- > > Key: WFCORE-40 > URL: https://issues.jboss.org/browse/WFCORE-40 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior) > Reporter: Stefan Schueffler > Assignee: James Perkins > Priority: Critical > Attachments: stack_140901_2254 > > > We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474) > Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore... > The partial stacktrace always is similar to this one: > {code} > "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000] > java.lang.Thread.State: BLOCKED (on object monitor) > at java.io.PrintStream.println(PrintStream.java:806) > - waiting to lock <0x5ee0adf8> (a java.io.PrintStream) > at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474) > at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) > {code} > While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization). > If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case. > My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 20:20:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 16 Mar 2017 20:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1482) FEEL: external java function references not working for functions with variable number of parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380065#comment-13380065 ] Edson Tirelli commented on DROOLS-1482: --------------------------------------- PR submitted: https://github.com/kiegroup/kie-dmn/pull/66 > FEEL: external java function references not working for functions with variable number of parameters > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-1482 > URL: https://issues.jboss.org/browse/DROOLS-1482 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > External Java functions with variable number of parameters not working. E.g.: > {code} > { > string format : function( mask, value ) external { > java : { > class : "java.lang.String", > method signature : "format( java.lang.String, [Ljava.lang.Object; )" > } > }, > format currency : function( amount ) > string format( "$%,4.2f", amount ), > result : format currency( 76499.3456 ) > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 20:22:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 20:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6771) Add suspend/resume utility for the test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFLY-6771. ------------------------------- Resolution: Rejected This is likely more work than it's worth. The PR was out of date so I just closed it. > Add suspend/resume utility for the test suite > --------------------------------------------- > > Key: WFLY-6771 > URL: https://issues.jboss.org/browse/WFLY-6771 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > Currently all suspend/resume tests just use the {{suspend}} and {{resume}} operations. A utility would be helpful to keep the suspend and resume functionality consistent. -There should also be a way to wait for the server to fully suspend and/or wait for the server to fully resume.- -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 20:23:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 16 Mar 2017 20:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4611) Review usage of hard-coded string constants with the application server name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFLY-4611. ------------------------------- Resolution: Rejected I no longer see the point of doing this. > Review usage of hard-coded string constants with the application server name > ---------------------------------------------------------------------------- > > Key: WFLY-4611 > URL: https://issues.jboss.org/browse/WFLY-4611 > Project: WildFly > Issue Type: Task > Reporter: James Perkins > Assignee: James Perkins > > This is meant to be a parent for all smaller issues that might creep up with hard-coded string constants for the application server name. For example if a message in a message bundle has {{WidFly Full 9.0.0..xxx started in...}} we need to ensure the server name is a variable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 02:05:00 2017 From: issues at jboss.org (Petr Kremensky (JIRA)) Date: Fri, 17 Mar 2017 02:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8396) Remove extra reloads from jca tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kremensky moved JBEAP-9649 to WFLY-8396: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8396 (was: JBEAP-9649) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.1.0.DR13) > Remove extra reloads from jca tests > ----------------------------------- > > Key: WFLY-8396 > URL: https://issues.jboss.org/browse/WFLY-8396 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Petr Kremensky > Assignee: Petr Kremensky > Priority: Minor > > There are some unnecessary server reloads in jca tests (integration basic module) > org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase > Revisit these and remove all servers which are not necessary. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 02:44:00 2017 From: issues at jboss.org (Petr Kremensky (JIRA)) Date: Fri, 17 Mar 2017 02:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8396) Remove extra reloads from jca tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kremensky updated WFLY-8396: --------------------------------- Description: There are some unnecessary server reloads in jca tests (integration basic module) org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase org.jboss.as.test.integration.jca.metrics.DataSourceCfgMetricUnitTestCase org.jboss.as.test.integration.jca.metrics.DriverCfgMetricUnitTestCase org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase Revisit these and remove all reloads which are not necessary. was: There are some unnecessary server reloads in jca tests (integration basic module) org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase Revisit these and remove all servers which are not necessary. > Remove extra reloads from jca tests > ----------------------------------- > > Key: WFLY-8396 > URL: https://issues.jboss.org/browse/WFLY-8396 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Petr Kremensky > Assignee: Petr Kremensky > Priority: Minor > > There are some unnecessary server reloads in jca tests (integration basic module) > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase > org.jboss.as.test.integration.jca.metrics.DataSourceCfgMetricUnitTestCase > org.jboss.as.test.integration.jca.metrics.DriverCfgMetricUnitTestCase > org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase > Revisit these and remove all reloads which are not necessary. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 03:09:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Fri, 17 Mar 2017 03:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2553) There isn't possibility set entry-type for new entry in Credential Store. In-Reply-To: References: Message-ID: Bartosz Baranowski created WFCORE-2553: ------------------------------------------ Summary: There isn't possibility set entry-type for new entry in Credential Store. Key: WFCORE-2553 URL: https://issues.jboss.org/browse/WFCORE-2553 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Bartosz Baranowski Assignee: Bartosz Baranowski -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 03:47:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Fri, 17 Mar 2017 03:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380125#comment-13380125 ] Chao Wang commented on WFCORE-2351: ----------------------------------- In the reported case, it can add condition to check service existence as {{if(controller != null)}} before putting element into noLongerMissingServices Map [ContainerStateMonitor.java#L182|https://github.com/wildfly/wildfly-core/blob/3.0.0.Beta9/controller/src/main/java/org/jboss/as/controller/ContainerStateMonitor.java#L182] to avoid the unnecessary message WFLYCTL0185. Hi [~brian.stansberry], If you have not started to work on this, I can send the PR with this change. > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2351 > URL: https://issues.jboss.org/browse/WFCORE-2351 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:33:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 17 Mar 2017 04:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8397) Create test cases for Elytron Principal Transformers In-Reply-To: References: Message-ID: Ondrej Lukas created WFLY-8397: ---------------------------------- Summary: Create test cases for Elytron Principal Transformers Key: WFLY-8397 URL: https://issues.jboss.org/browse/WFLY-8397 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Ondrej Lukas Create test cases for following Elytron Principal Transformers: * constant-principal-transformer * regex-principal-transformer * regex-validating-principal-transformer * chained-principal-transformer Test case for aggregate-principal-transformer cannot developed due to WFCORE-2547. Once meaning of aggregate-principal-transformer will be revisited then appropriate test case will be added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:42:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 17 Mar 2017 04:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8398) (7.1.0) AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman moved JBEAP-9656 to WFLY-8398: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8398 (was: JBEAP-9656) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > (7.1.0) AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null > --------------------------------------------------------------------------- > > Key: WFLY-8398 > URL: https://issues.jboss.org/browse/WFLY-8398 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Labels: legacy > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:42:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 17 Mar 2017 04:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8398) AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated WFLY-8398: ------------------------------- Summary: AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null (was: (7.1.0) AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null) > AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null > ------------------------------------------------------------------- > > Key: WFLY-8398 > URL: https://issues.jboss.org/browse/WFLY-8398 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Labels: legacy > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:48:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 17 Mar 2017 04:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8399) Upgrade jboss-negotiation to 3.0.4 In-Reply-To: References: Message-ID: Tomas Hofman created WFLY-8399: ---------------------------------- Summary: Upgrade jboss-negotiation to 3.0.4 Key: WFLY-8399 URL: https://issues.jboss.org/browse/WFLY-8399 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Tomas Hofman Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:48:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 17 Mar 2017 04:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8399) Upgrade jboss-negotiation to 3.0.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated WFLY-8399: ------------------------------- Summary: Upgrade jboss-negotiation to 3.0.5 (was: Upgrade jboss-negotiation to 3.0.4) > Upgrade jboss-negotiation to 3.0.5 > ---------------------------------- > > Key: WFLY-8399 > URL: https://issues.jboss.org/browse/WFLY-8399 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Reporter: Tomas Hofman > Assignee: Darran Lofthouse > Labels: legacy > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:48:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 17 Mar 2017 04:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8400) Upgrade jboss-negotiation to 3.0.5 In-Reply-To: References: Message-ID: Tomas Hofman created WFLY-8400: ---------------------------------- Summary: Upgrade jboss-negotiation to 3.0.5 Key: WFLY-8400 URL: https://issues.jboss.org/browse/WFLY-8400 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Tomas Hofman Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 04:54:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Fri, 17 Mar 2017 04:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2554) batch --file=... could ignore empty lines in file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise moved JBEAP-9659 to WFCORE-2554: ----------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2554 (was: JBEAP-9659) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: (was: 7.1.0.DR14) > batch --file=... could ignore empty lines in file > ------------------------------------------------- > > Key: WFCORE-2554 > URL: https://issues.jboss.org/browse/WFCORE-2554 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > batch command could ignore empty lines in file > {code} > domain at localhost:9990 /] batch --file=/tmp/ely.cli > Failed to create batch from /tmp/ely.cli: The line is null or empty. > {code} > cli file contains: > {code} > command > > command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:00:00 2017 From: issues at jboss.org (Jochen Welle (JIRA)) Date: Fri, 17 Mar 2017 05:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1483) Support default expiration for events In-Reply-To: References: Message-ID: Jochen Welle created DROOLS-1483: ------------------------------------ Summary: Support default expiration for events Key: DROOLS-1483 URL: https://issues.jboss.org/browse/DROOLS-1483 Project: Drools Issue Type: Feature Request Environment: Drools >= 6.5 in STREAM mode Reporter: Jochen Welle Assignee: Edson Tirelli We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. Benefits would be: * Expiration is guaranteed: either after the specified offset or after the inferred offset. * Rule authors are not required to include a temporal constraint in all rules. * Event classes can be designed if the rules are not yet known. The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. {code:java} @Role(Type.EVENT) @Expires(value = "10m") // fixed expiration offset or @Expires(value = "10m", type="fixed") // fixed expiration offset public class MyEvent { ... {code} New behavior: {code:java} @Role(Type.EVENT) @Expires(value = "10m", type="default") // new feature public class MyEvent { ... {code} The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. This feature is related to: * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:04:00 2017 From: issues at jboss.org (Jochen Welle (JIRA)) Date: Fri, 17 Mar 2017 05:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1483) Support default expiration for events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Welle updated DROOLS-1483: --------------------------------- Description: We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. Benefits would be: * Expiration is guaranteed: either after the specified offset or after the inferred offset. * Rule authors are not required to include a temporal constraint in all rules. * Event classes can be designed if the rules are not yet known. The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. {code:java} @Role(Type.EVENT) @Expires(value = "10m") // fixed expiration offset or @Expires(value = "10m", type="fixed") // fixed expiration offset public class MyEvent { ... {code} New behavior: {code:java} @Role(Type.EVENT) @Expires(value = "10m", type="default") // new feature public class MyEvent { ... {code} The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. This feature is related to: * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] was: We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. Benefits would be: * Expiration is guaranteed: either after the specified offset or after the inferred offset. * Rule authors are not required to include a temporal constraint in all rules. * Event classes can be designed if the rules are not yet known. The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. {code:java} @Role(Type.EVENT) @Expires(value = "10m") // fixed expiration offset or @Expires(value = "10m", type="fixed") // fixed expiration offset public class MyEvent { ... {code} New behavior: {code:java} @Role(Type.EVENT) @Expires(value = "10m", type="default") // new feature public class MyEvent { ... {code} The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. This feature is related to: * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] > Support default expiration for events > ------------------------------------- > > Key: DROOLS-1483 > URL: https://issues.jboss.org/browse/DROOLS-1483 > Project: Drools > Issue Type: Feature Request > Environment: Drools >= 6.5 in STREAM mode > Reporter: Jochen Welle > Assignee: Edson Tirelli > > We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. > Benefits would be: > * Expiration is guaranteed: either after the specified offset or after the inferred offset. > * Rule authors are not required to include a temporal constraint in all rules. > * Event classes can be designed if the rules are not yet known. > The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m") // fixed expiration offset or > @Expires(value = "10m", type="fixed") // fixed expiration offset > public class MyEvent { > ... > {code} > New behavior: > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m", type="default") // new feature > public class MyEvent { > ... > {code} > The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. > This feature is related to: > * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] > * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:40:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 17 Mar 2017 05:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380183#comment-13380183 ] Ingo Weiss commented on JBJCA-1341: ----------------------------------- I agree with trimming the messages, that's fine. About the {{,}} char, I refactored to use {{.contains()}} instead of {{.equalsIgnoreCase()}}, that should take care of it. > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:44:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=) Date: Fri, 17 Mar 2017 05:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1363) revapi-maven-plugin forks exutions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380185#comment-13380185 ] Petr ?irok? commented on DROOLS-1363: ------------------------------------- [~mmacik] I believe this has been fixed few weeks back with the upgrade of the plugin. Could you please confirm and possibly mark this as resolved? > revapi-maven-plugin forks exutions > ---------------------------------- > > Key: DROOLS-1363 > URL: https://issues.jboss.org/browse/DROOLS-1363 > Project: Drools > Issue Type: Bug > Components: build > Reporter: Petr ?irok? > Assignee: Mari?n Macik > > Revapi Maven plugin, as used in kie-api, forks the exeuctions causing almost the whole build to be executed three times. This needs to be fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:46:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Fri, 17 Mar 2017 05:46:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8397) Create test cases for Elytron Principal Transformers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas reassigned WFLY-8397: ---------------------------------- Assignee: Ondrej Lukas > Create test cases for Elytron Principal Transformers > ---------------------------------------------------- > > Key: WFLY-8397 > URL: https://issues.jboss.org/browse/WFLY-8397 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > > Create test cases for following Elytron Principal Transformers: > * constant-principal-transformer > * regex-principal-transformer > * regex-validating-principal-transformer > * chained-principal-transformer > Test case for aggregate-principal-transformer cannot developed due to WFCORE-2547. Once meaning of aggregate-principal-transformer will be revisited then appropriate test case will be added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:46:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=) Date: Fri, 17 Mar 2017 05:46:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-573) Kie Server: bugs and enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr ?irok? resolved DROOLS-573. -------------------------------- Resolution: Done I marking this as resolved as all the issues were likely solved long time ago. > Kie Server: bugs and enhancements > --------------------------------- > > Key: DROOLS-573 > URL: https://issues.jboss.org/browse/DROOLS-573 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta1 > Reporter: Petr ?irok? > Assignee: Edson Tirelli > > As discussed with Edson, I am creating list of possible bugs and enhancements for the KIE Server. > Bugs: > * Server returns NPE when the request body is empty (and is required). This happens for example when creating new container using /container/{id}, but not providing any data within the body (the XML/JSON specifying release-id, etc). > * The server returns 201 (Created) even when the container was not actually created. Easy reproducer: try to create container using non-existing kjar GAV. The response code will be 201 and the response will be failure with message "Failed to create container 1...." > Enhancements: > * I think it it would useful to move the KieServer interface into -api module so that user's can use e.g. RestEasy ClientProxy to create own REST client in case the don't want to use the provided client. > * When deplying the WAR into EAP 6.3.0 warning is dispalyed: JBAS016012: Deployment deployment "kie-server.war" contains CDI annotations but beans.xml was not found. The WAR file should contain beans.xml. > The description will be updated if I found more such bugs/enhancements. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:51:00 2017 From: issues at jboss.org (Jim Ma (JIRA)) Date: Fri, 17 Mar 2017 05:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8369) resteasy.scan parameter doesn't need to be handled in JaxrsIntegrationProcessor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma updated WFLY-8369: ------------------------- Summary: resteasy.scan parameter doesn't need to be handled in JaxrsIntegrationProcessor (was: jaxrs bootstrap servlet init parameters doesn't work) > resteasy.scan parameter doesn't need to be handled in JaxrsIntegrationProcessor > ------------------------------------------------------------------------------- > > Key: WFLY-8369 > URL: https://issues.jboss.org/browse/WFLY-8369 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 11.0.0.Alpha1 > > > resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:52:00 2017 From: issues at jboss.org (Jim Ma (JIRA)) Date: Fri, 17 Mar 2017 05:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8369) resteasy.scan parameter doesn't need to be handled in JaxrsIntegrationProcessor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma updated WFLY-8369: ------------------------- Description: resteasy.scan , resteasy.scan.provider and resteasy.scan.resources are already processed in JaxrsScanningProcessor. There is no effect to handle it in JaxrsIntegrationProcessor was:resteasy.scan , resteasy.scan.provider and resteasy.scan.resources in servlet context can be set to ResteasyDeployment and it works. But these parameter values from resteasy bootstrap servlet init paramter are ignored. > resteasy.scan parameter doesn't need to be handled in JaxrsIntegrationProcessor > ------------------------------------------------------------------------------- > > Key: WFLY-8369 > URL: https://issues.jboss.org/browse/WFLY-8369 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 11.0.0.Alpha1 > > > resteasy.scan , resteasy.scan.provider and resteasy.scan.resources are already processed in JaxrsScanningProcessor. There is no effect to handle it in JaxrsIntegrationProcessor -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 05:54:00 2017 From: issues at jboss.org (Jim Ma (JIRA)) Date: Fri, 17 Mar 2017 05:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8369) resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma updated WFLY-8369: ------------------------- Summary: resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor (was: resteasy.scan parameter doesn't need to be handled in JaxrsIntegrationProcessor) > resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor > ------------------------------------------------------------------------------------------ > > Key: WFLY-8369 > URL: https://issues.jboss.org/browse/WFLY-8369 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 11.0.0.Alpha1 > > > resteasy.scan , resteasy.scan.provider and resteasy.scan.resources are already processed in JaxrsScanningProcessor. There is no effect to handle it in JaxrsIntegrationProcessor -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 06:04:01 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 17 Mar 2017 06:04:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated JBJCA-1341: ------------------------------ Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/613, https://github.com/ironjacamar/ironjacamar/pull/612, https://github.com/ironjacamar/ironjacamar/pull/611 (was: https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607, https://github.com/ironjacamar/ironjacamar/pull/608) > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 07:05:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 17 Mar 2017 07:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2555) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: Hynek ?v?bek created WFCORE-2555: ------------------------------------ Summary: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. Key: WFCORE-2555 URL: https://issues.jboss.org/browse/WFCORE-2555 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is few places where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 07:12:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 17 Mar 2017 07:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2555) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFCORE-2555: --------------------------------- Description: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is one place when we store new entry and where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 was: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is few places where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > ----------------------------------------------------------------------------- > > Key: WFCORE-2555 > URL: https://issues.jboss.org/browse/WFCORE-2555 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. > There is one place when we store new entry and where is not key in lowercase. > e.g. > https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 07:36:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 17 Mar 2017 07:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2555) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek reassigned WFCORE-2555: ------------------------------------ Assignee: Hynek ?v?bek (was: Darran Lofthouse) > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > ----------------------------------------------------------------------------- > > Key: WFCORE-2555 > URL: https://issues.jboss.org/browse/WFCORE-2555 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Hynek ?v?bek > > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. > There is one place when we store new entry and where is not key in lowercase. > e.g. > https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 07:38:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 17 Mar 2017 07:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2555) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFCORE-2555: --------------------------------- Description: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys). When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is one place when we store new entry and where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 was: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is one place when we store new entry and where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > ----------------------------------------------------------------------------- > > Key: WFCORE-2555 > URL: https://issues.jboss.org/browse/WFCORE-2555 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Hynek ?v?bek > > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys). > When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. > There is one place when we store new entry and where is not key in lowercase. > e.g. > https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 07:39:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 17 Mar 2017 07:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2555) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFCORE-2555: --------------------------------- Steps to Reproduce: mvn clean install -Dtest=KeystorePasswordStoreTest#testCaseInsensitiveAlias (now it is waiting for mege https://github.com/wildfly-security/wildfly-elytron/pull/603) > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > ----------------------------------------------------------------------------- > > Key: WFCORE-2555 > URL: https://issues.jboss.org/browse/WFCORE-2555 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Hynek ?v?bek > > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys). > When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. > There is one place when we store new entry and where is not key in lowercase. > e.g. > https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 07:39:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 17 Mar 2017 07:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2555) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated WFCORE-2555: --------------------------------- Description: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is one place when we store new entry and where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 was: Cache in KeyStoreCredentialStore must work with lowercase aliases (keys). When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. There is one place when we store new entry and where is not key in lowercase. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > ----------------------------------------------------------------------------- > > Key: WFCORE-2555 > URL: https://issues.jboss.org/browse/WFCORE-2555 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Hynek ?v?bek > > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. > There is one place when we store new entry and where is not key in lowercase. > e.g. > https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:00:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Fri, 17 Mar 2017 08:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2556) Aliases in credential stores should be case insensitive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet moved WFLY-8131 to WFCORE-2556: ------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2556 (was: WFLY-8131) Component/s: Security (was: Security) > Aliases in credential stores should be case insensitive > ------------------------------------------------------- > > Key: WFCORE-2556 > URL: https://issues.jboss.org/browse/WFCORE-2556 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store, user_experience > > Working with credential store aliases should be case insensitive. > Current behavior, when aliases are converted to lowercase during add operation is not user-friendly. Subsequent operations should also support automatic conversion to lowercase. > E.g. > {code} > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:add(secret-value=password) > /subsystem=elytron/credential-store=cred-store-default/alias=UPPER:remove() > {code} > *Current behavior:* > First command succeeds and the second fails as the alias is changed to "upper" (in lowercase). > *Expected behavior:* > Both commans succeeds. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8131 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:00:01 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 17 Mar 2017 08:00:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7738) XTS suspend tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky updated WFLY-7738: -------------------------------- Component/s: XTS > XTS suspend tests fail with security manager > -------------------------------------------- > > Key: WFLY-7738 > URL: https://issues.jboss.org/browse/WFLY-7738 > Project: WildFly > Issue Type: Bug > Components: Test Suite, Web Services, XTS > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=AtomicTransactionSuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-5) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsat.AtomicTransactionExecutionService.init(AtomicTransactionExecutionService.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} > *org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BusinessActivitySuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-3) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsba.BusinessActivityExecutionService.init(BusinessActivityExecutionService.java:76) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:36:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 17 Mar 2017 08:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned WFCORE-2549: ---------------------------------------- Assignee: Darran Lofthouse (was: Brian Stansberry) > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:37:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 17 Mar 2017 08:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380279#comment-13380279 ] Darran Lofthouse commented on WFCORE-2549: ------------------------------------------ Just re-assigning as a parser change is also required. > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:38:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Fri, 17 Mar 2017 08:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8401) create smoke test to mixed domain test suite where master has only elytron configured and no legacy security realm In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka moved JBEAP-9667 to WFLY-8401: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8401 (was: JBEAP-9667) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) > create smoke test to mixed domain test suite where master has only elytron configured and no legacy security realm > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-8401 > URL: https://issues.jboss.org/browse/WFLY-8401 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Martin Simka > Assignee: Martin Simka > > create smoke test to mixed domain test suite where master has only elytron configured and no legacy security realm -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:41:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Fri, 17 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1482) FEEL: external java function references not working for functions with variable number of parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli resolved DROOLS-1482. ----------------------------------- Resolution: Done > FEEL: external java function references not working for functions with variable number of parameters > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-1482 > URL: https://issues.jboss.org/browse/DROOLS-1482 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > External Java functions with variable number of parameters not working. E.g.: > {code} > { > string format : function( mask, value ) external { > java : { > class : "java.lang.String", > method signature : "format( java.lang.String, [Ljava.lang.Object; )" > } > }, > format currency : function( amount ) > string format( "$%,4.2f", amount ), > result : format currency( 76499.3456 ) > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:41:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 17 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBEE-175) FactoryFinder requires more privileged blocks if Security Manager is enabled In-Reply-To: References: Message-ID: Ivo Studensky created JBEE-175: ---------------------------------- Summary: FactoryFinder requires more privileged blocks if Security Manager is enabled Key: JBEE-175 URL: https://issues.jboss.org/browse/JBEE-175 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-saaj-api Reporter: Ivo Studensky Assignee: Ivo Studensky When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. Affected version: jboss-saaj-api_1.3_spec-1.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:45:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 17 Mar 2017 08:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBEE-175) FactoryFinder requires more privileged blocks if Security Manager is enabled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBEE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky updated JBEE-175: ------------------------------- Git Pull Request: https://github.com/jboss/jboss-saaj-api_spec/pull/3 > FactoryFinder requires more privileged blocks if Security Manager is enabled > ----------------------------------------------------------------------------- > > Key: JBEE-175 > URL: https://issues.jboss.org/browse/JBEE-175 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-saaj-api > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. > Affected version: jboss-saaj-api_1.3_spec-1.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:47:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 17 Mar 2017 08:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBEE-176) FactoryFinder requires more privileged blocks if Security Manager is enabled In-Reply-To: References: Message-ID: Ivo Studensky created JBEE-176: ---------------------------------- Summary: FactoryFinder requires more privileged blocks if Security Manager is enabled Key: JBEE-176 URL: https://issues.jboss.org/browse/JBEE-176 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jaxws-api Reporter: Ivo Studensky Assignee: Ivo Studensky When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. Affected version: jboss-jaxws-api_2.2_spec-2.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:51:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 17 Mar 2017 08:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBEE-176) FactoryFinder requires more privileged blocks if Security Manager is enabled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBEE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky updated JBEE-176: ------------------------------- Git Pull Request: https://github.com/jboss/jboss-jaxws-api_spec/pull/5 > FactoryFinder requires more privileged blocks if Security Manager is enabled > ---------------------------------------------------------------------------- > > Key: JBEE-176 > URL: https://issues.jboss.org/browse/JBEE-176 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jaxws-api > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. > Affected version: jboss-jaxws-api_2.2_spec-2.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 08:56:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 17 Mar 2017 08:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1483) Support default expiration for events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-1483: ----------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Support default expiration for events > ------------------------------------- > > Key: DROOLS-1483 > URL: https://issues.jboss.org/browse/DROOLS-1483 > Project: Drools > Issue Type: Feature Request > Environment: Drools >= 6.5 in STREAM mode > Reporter: Jochen Welle > Assignee: Mario Fusco > > We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. > Benefits would be: > * Expiration is guaranteed: either after the specified offset or after the inferred offset. > * Rule authors are not required to include a temporal constraint in all rules. > * Event classes can be designed if the rules are not yet known. > The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m") // fixed expiration offset or > @Expires(value = "10m", type="fixed") // fixed expiration offset > public class MyEvent { > ... > {code} > New behavior: > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m", type="default") // new feature > public class MyEvent { > ... > {code} > The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. > This feature is related to: > * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] > * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 09:22:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 17 Mar 2017 09:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1484) Move SessionPseudoClock to public kie-api In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1484: ----------------------------------- Summary: Move SessionPseudoClock to public kie-api Key: DROOLS-1484 URL: https://issues.jboss.org/browse/DROOLS-1484 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 09:46:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 17 Mar 2017 09:46:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups In-Reply-To: References: Message-ID: Jeff Mesnil created WFCORE-2557: ----------------------------------- Summary: Can not parse 2 complex attributes with same XML element name in 2 different attribute groups Key: WFCORE-2557 URL: https://issues.jboss.org/browse/WFCORE-2557 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Beta9 Reporter: Jeff Mesnil Assignee: Brian Stansberry This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: - target-credential-reference (attribute group = target, xml element name = credential-reference) - source-credential-reference (attribute group = source, xml element name = credential-reference) with the corresponding XML structure: {code} {code} The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 09:50:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 17 Mar 2017 09:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380320#comment-13380320 ] Jeff Mesnil commented on WFCORE-2557: ------------------------------------- [~ctomc] I wrote a test case to reproduce the issue in wildfly-core test suite: https://github.com/jmesnil/wildfly-core/tree/WFCORE-2557_complex_attribute_parser > Can not parse 2 complex attributes with same XML element name in 2 different attribute groups > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2557 > URL: https://issues.jboss.org/browse/WFCORE-2557 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: > - target-credential-reference (attribute group = target, xml element name = credential-reference) > - source-credential-reference (attribute group = source, xml element name = credential-reference) > with the corresponding XML structure: > {code} > > > > > > > > > {code} > The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 09:53:00 2017 From: issues at jboss.org (Michael Foley (JIRA)) Date: Fri, 17 Mar 2017 09:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-24) HOSA --- Hawkular Agent for Openshift In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Foley updated HAWKULARQE-24: ------------------------------------ an update from viet https://gist.github.com/vnugent/0b1fb80c14d4c95ddf527318a57fdb80 > HOSA --- Hawkular Agent for Openshift > ------------------------------------- > > Key: HAWKULARQE-24 > URL: https://issues.jboss.org/browse/HAWKULARQE-24 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: viet nguyen > > Top level task for HOSA. > All the work required goes here as sub-tasks. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 10:30:00 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 17 Mar 2017 10:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer resolved DROOLS-1048. -------------------------------------------- Resolution: Done > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > https://help.github.com/articles/renaming-an-organization/ > Preparation: > 1) Get some experience > - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from foo_org > -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and rename it from foo_org to foo_org_kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > More stuff to try: > - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? > 2) (Optional - not needed now that we are renaming org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be renaming the org. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Freeze starts, announce in capitals on every IRC channel > - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). > - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > - Freeze stops, announce in capitals on every IRC channel > 6) Clean up the fallout > - Change the pom.xml scm tag for master (in all repo's that ref it) > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: > -- all code > -- openhub > -- jira > -- fisheye > -- .org websites (incl jboss.properties) > -- jboss.org > - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 10:51:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 17 Mar 2017 10:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-2557: ----------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > Can not parse 2 complex attributes with same XML element name in 2 different attribute groups > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2557 > URL: https://issues.jboss.org/browse/WFCORE-2557 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Tomaz Cerar > > This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: > - target-credential-reference (attribute group = target, xml element name = credential-reference) > - source-credential-reference (attribute group = source, xml element name = credential-reference) > with the corresponding XML structure: > {code} > > > > > > > > > {code} > The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 10:51:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 17 Mar 2017 10:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380351#comment-13380351 ] Tomaz Cerar commented on WFCORE-2557: ------------------------------------- Tnx [~jmesnil] Will prepare a fix asap. > Can not parse 2 complex attributes with same XML element name in 2 different attribute groups > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2557 > URL: https://issues.jboss.org/browse/WFCORE-2557 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Tomaz Cerar > > This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: > - target-credential-reference (attribute group = target, xml element name = credential-reference) > - source-credential-reference (attribute group = source, xml element name = credential-reference) > with the corresponding XML structure: > {code} > > > > > > > > > {code} > The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 10:57:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 17 Mar 2017 10:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from Tech Preview release to CFME 4.5 release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380357#comment-13380357 ] Hayk Hovsepyan commented on HAWKULARQE-30: ------------------------------------------ BZ is fixed and verified. Test case was run and both metrics and inventory data are remaining after upgrade. > [QE] - Upgrade CFME from Tech Preview release to CFME 4.5 release > ----------------------------------------------------------------- > > Key: HAWKULARQE-30 > URL: https://issues.jboss.org/browse/HAWKULARQE-30 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > This task supposes to have setup Tech Preview CFME containers , including CFME, Hawkular Services, Cassandra and EAP7 containers. > The task is to upgrade all these Containers into CFME 4.5 release images. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 10:58:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 17 Mar 2017 10:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from Tech Preview release to CFME 4.5 release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan resolved HAWKULARQE-30. -------------------------------------- Release Notes Text: Upgrade is tested, no regression or Bug was found. Resolution: Done > [QE] - Upgrade CFME from Tech Preview release to CFME 4.5 release > ----------------------------------------------------------------- > > Key: HAWKULARQE-30 > URL: https://issues.jboss.org/browse/HAWKULARQE-30 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > This task supposes to have setup Tech Preview CFME containers , including CFME, Hawkular Services, Cassandra and EAP7 containers. > The task is to upgrade all these Containers into CFME 4.5 release images. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 11:03:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 17 Mar 2017 11:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1473) Create a camel component to integrate the kie-server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380360#comment-13380360 ] Mario Fusco commented on DROOLS-1473: ------------------------------------- Implemented by https://github.com/kiegroup/droolsjbpm-build-bootstrap/commit/1d8166b484ff3c0de324c2af52b468bef6a7d747 and https://github.com/kiegroup/droolsjbpm-integration/commit/e2ba2d3ed2fc559a269583b1ab1f95370603b075 I'm not resolving this jira yet because it is still necessary to find an automatic mechanism to know if a given parameter should be read by the header or the body of the camel's exchange. > Create a camel component to integrate the kie-server > ---------------------------------------------------- > > Key: DROOLS-1473 > URL: https://issues.jboss.org/browse/DROOLS-1473 > Project: Drools > Issue Type: Bug > Components: integration > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 11:25:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 17 Mar 2017 11:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1484) Move SessionPseudoClock to public kie-api In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-1484. --------------------------------- Fix Version/s: 7.0.0.Beta8 Resolution: Done Implemented by https://github.com/kiegroup/droolsjbpm-knowledge/commit/563c5271fe054fd0c6cc1f03338833bfefb2e819 https://github.com/kiegroup/drools/commit/66ef7b36a3bb72f976643a9c5107dcb5c5d19826 https://github.com/kiegroup/jbpm/commit/a2d34131bd3ae7e1d0657cdc2c216019c849e1b5 > Move SessionPseudoClock to public kie-api > ----------------------------------------- > > Key: DROOLS-1484 > URL: https://issues.jboss.org/browse/DROOLS-1484 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 7.0.0.Beta8 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 11:58:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Fri, 17 Mar 2017 11:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1485) Add a string( mask, p... ) function to format strings according to the mask In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1485: ------------------------------------- Summary: Add a string( mask, p... ) function to format strings according to the mask Key: DROOLS-1485 URL: https://issues.jboss.org/browse/DROOLS-1485 Project: Drools Issue Type: Feature Request Components: dmn engine Affects Versions: 7.0.0.Beta7 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final Add a second signature to the string() function that works like the java String.format() method and allows the user to format strings in arbitrary ways. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 12:02:00 2017 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Fri, 17 Mar 2017 12:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8402) DescriptorScheduleTestCase fails when upgrading to jboss metadata 10.0.1.Final In-Reply-To: References: Message-ID: Panagiotis Sotiropoulos created WFLY-8402: --------------------------------------------- Summary: DescriptorScheduleTestCase fails when upgrading to jboss metadata 10.0.1.Final Key: WFLY-8402 URL: https://issues.jboss.org/browse/WFLY-8402 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos DescriptorScheduleTestCase fails when upgrading to jboss metadata 10.0.1.Final because of https://github.com/jboss/metadata/blob/master/ejb/src/main/java/org/jboss/metadata/ejb/parser/spec/TimerMetaDataParser.java#L130 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 12:04:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Fri, 17 Mar 2017 12:04:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2546) Typo in description of Elytron aggregate-principal-transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2546: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Typo in description of Elytron aggregate-principal-transformer > -------------------------------------------------------------- > > Key: WFCORE-2546 > URL: https://issues.jboss.org/browse/WFCORE-2546 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > There is typo in description of Elytron aggregate-principal-transformer in CLI. There is {{principa}} instead of {{principal}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 12:13:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Fri, 17 Mar 2017 12:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2254) InterdependentDeploymentTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFCORE-2254: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2174, https://github.com/wildfly/wildfly-core/pull/2264 (was: https://github.com/wildfly/wildfly-core/pull/2174) > 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: Ingo Weiss > Fix For: 3.0.0.Alpha25 > > > *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 )" 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) From issues at jboss.org Fri Mar 17 12:34:01 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Fri, 17 Mar 2017 12:34:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1485) Add a string( mask, p... ) function to format strings according to the mask In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli resolved DROOLS-1485. ----------------------------------- Resolution: Done > Add a string( mask, p... ) function to format strings according to the mask > --------------------------------------------------------------------------- > > Key: DROOLS-1485 > URL: https://issues.jboss.org/browse/DROOLS-1485 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.0.0.Final > > > Add a second signature to the string() function that works like the java String.format() method and allows the user to format strings in arbitrary ways. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 15:49:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 17 Mar 2017 15:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7337) Introduce an authorization SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380470#comment-13380470 ] David Lloyd commented on WFLY-7337: ----------------------------------- We can close this now I think, as the container can manage all these authorization checks and we are doing so presently by way of a permission check on access to the remote JTA service. > Introduce an authorization SPI > ------------------------------ > > Key: WFLY-7337 > URL: https://issues.jboss.org/browse/WFLY-7337 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 16:22:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 16:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380482#comment-13380482 ] Brian Stansberry commented on WFCORE-2351: ------------------------------------------ [~soul2zimate] I think the fix is something different, although you are on the right track regarding checking if a service controller is still installed. Here's what's going on: AbstractOperationContext.processStages() before going to Stage.VERIFY calls awaitServiceContainerStability() which eventually calls ContainerStateMonitor.createContainerStateChangeReport(false). *Nothing is logged at this point* (which is deliberate), but the internal fields in ContainerStateMonitor get populated with some data. The logging at 16:54:18,810 comes from ContainerStateMonitor.logContainerStateChangesAndReset() which indirectly is called by OperationContextImpl.Step.releaseStepLocks. This is called when the operation is completing. In this case the op has rolled back, and therefore there is no unsatisfied dependency any more! But the logging at 16:54:18,810 is as if the rollback hasn't occurred. Then the next op comes along, and when it completes and reaches OperationContextImpl.Step.releaseStepLocks, that's when another report is generated that reports the "correction" that actually occurred during the rollback of the previous op. The reason you get a report after the second op is ContainerStateMonitor is not left in the correct state after the first op completes. ContainerStateMonitor.previousMissingDepSet should be empty at that point. The cause of that not being empty is that when ContainerStateMonitor.createContainerStateChangeReport is called the 2nd time in the first op, the time that produces logging, it uses the 'failed' and 'problems' sets. But those sets can contain ServiceControllers that were added over the course of execution of the op, but which are no longer installed (because the op rolled back). If they are no longer installed, they are no longer "problems" or "failed" so they should be ignored when creating the report. https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-2351 does that (sorry; I kind of hide the key change behind some refactoring to use Collections.emptySet/Map where possible.) Doing that makes the bogus report after the 2nd op go away. A problem is it makes the first report at 16:54:18,810 go away as well. Perhaps that's good! Quite a few people dislike those messages; they can be quite noisy. And if the end result of the operation is that MSC has no failed services or missing dependencies, then there's nothing to report. But I'm a bit reluctant to just drop that first report. I could restore it by having the call from AbstractOperationContext.processStages() result in logging, and then the OperationContextImpl.Step.releaseStepLocks call also logs, but now reporting the "no longer missing" services. So basically the 2 log statements shown in the description, but now the 2nd one is at the right time. Having those 2 log messages right after one another is also kind of noisy, plus confusing. To reduce the confusion there would probably have to be some sort of INFO message in between saying the op is being rolled back, which helps explain the 2nd report. There would be other issue too with logging twice. For example what if a service is failed and rollback-on-runtime-failure=false is used so there's no rollback? We don't want log the same failed service twice for one op. I'll have to think whether I want that 16:54:18,810 logging even when the op rolls back. The basic point of the report is to report unusual MSC state at the end of an op, so really it's pointless to log it if the end state of the op has no unusual MSC state. The log already has ERROR messages for the missing / failed services that were detected while the op executed. > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2351 > URL: https://issues.jboss.org/browse/WFCORE-2351 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 16:38:00 2017 From: issues at jboss.org (Flavia Rainone (JIRA)) Date: Fri, 17 Mar 2017 16:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1342) Lazy Enlistment expects active transaction In-Reply-To: References: Message-ID: Flavia Rainone created JBJCA-1342: ------------------------------------- Summary: Lazy Enlistment expects active transaction Key: JBJCA-1342 URL: https://issues.jboss.org/browse/JBJCA-1342 Project: IronJacamar Issue Type: Bug Components: Deployer Reporter: Flavia Rainone Assignee: Flavia Rainone Lazy enlistment fails when there is no active transaction: javax.resource.ResourceException: IJ000652: Unable to obtain lock org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.lazyEnlist(TxConnectionManagerImpl.java:820) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 17:28:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 17:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on AttributeDefinitions where a capability is referenced. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-840. ------------------------------------- Resolution: Out of Date The unambiguous case no longer requires you to provide the name of the dependent capability. > Improve API on AttributeDefinitions where a capability is referenced. > --------------------------------------------------------------------- > > Key: WFCORE-840 > URL: https://issues.jboss.org/browse/WFCORE-840 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.0.0.Alpha11 > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > > Take the following method call defining an attribute: - > {code} > .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true) > {code} > This definition says this attribute references something which provides the PROVIDERS_CAPABILITY. > However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY. > Really what the resource provides is not directly related to this attribute definition. > The following pull request has already improved on registering in advance what capability a resource can provide: - > https://github.com/wildfly/wildfly-core/pull/909 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 18:47:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 18:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-381) DefaultPropertyReplacer can't handle ${:} expression In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved JBMETA-381. ------------------------------------- Fix Version/s: 8.1.1.Final 7.2.0.Final Resolution: Done > DefaultPropertyReplacer can't handle ${:} expression > ---------------------------------------------------- > > Key: JBMETA-381 > URL: https://issues.jboss.org/browse/JBMETA-381 > Project: JBoss Metadata > Issue Type: Bug > Components: common > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.1.1.Final, 7.2.0.Final > > > If the string "${:}" is passed to default property replacer, it does not parse it as indicating File.pathSeparator; rather it treats it as the default delimiter. > ${:} resolves to an empty string. > a${:} resolves to a > ${:}a resolves to a -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 18:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 18:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1058) Encapsulate logic to specify dynamic capability name resolution from a PathAddress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-1058: ---------------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) [~ctomc] I believe this is done. > Encapsulate logic to specify dynamic capability name resolution from a PathAddress > ---------------------------------------------------------------------------------- > > Key: WFCORE-1058 > URL: https://issues.jboss.org/browse/WFCORE-1058 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > > One can create a capability whose dynamic name is not resolved using the value of the last element of a path address (e.g. using the value of a parent resource). In this case, the logic for generating the dynamic name need to be modified in multiple places. > # CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder.getDynamicDependentName(...) > # AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) > # AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...) > For reference, the clustering subsystems handle this via a custom abstraction: > https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main/java/org/jboss/as/clustering/controller/Capability.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 19:09:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 19:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in InterDeploymentDependenciesEarTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFLY-8148. ------------------------------------ Resolution: Duplicate Issue > Intermittent failure in InterDeploymentDependenciesEarTestCase > -------------------------------------------------------------- > > Key: WFLY-8148 > URL: https://issues.jboss.org/browse/WFLY-8148 > Project: WildFly > Issue Type: Bug > Components: EE, Test Suite > Reporter: Brian Stansberry > > On a fairly frequent basis we are seeing failures in InterDeploymentDependenciesEarTestCase. This then seems to be followed by ~ 200 other failures. > https://ci.wildfly.org/viewLog.html?buildId=46213&buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration is an example. > Pattern is: > Failure: > {code} > javax.ejb.NoSuchEJBException: No such EJB: app2/hello/LogAccessBean > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:354) > at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:75) > at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:357) > at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:608) > at org.jboss.ejb.client.EJBInvocationHandler.lambda$invoke$0(EJBInvocationHandler.java:164) > at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:428) > at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:387) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:150) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100) > at com.sun.proxy.$Proxy65.getLog(Unknown Source) > at org.jboss.as.test.integration.deployment.dependencies.ear.InterDeploymentDependenciesEarTestCase.test(InterDeploymentDependenciesEarTestCase.java:127) > {code} > Earliest failure I see with this pattern in the TeamCity history is from Aug 17, 2016. But such failures were confined to JDK9 runs and stopped last Sept 2. Then they start appearing quite frequently on Feb 6, 2017. First appearance was in a test of PR #9600, but there are other failures before that PR was merged so I doubt that PR is relevant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 19:16:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 19:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3030) Test Suite is not security manager-aware In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFLY-3030. ------------------------------------ Resolution: Out of Date While this is by no means all cleaned up, I'm going to resolve this as out of date as since this was filed there have been and still are a great many separate issues tracking particular problems. > Test Suite is not security manager-aware > ---------------------------------------- > > Key: WFLY-3030 > URL: https://issues.jboss.org/browse/WFLY-3030 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 8.0.0.Final > Reporter: David Lloyd > > Our test suite has over 1000 failures running in security manager mode ({{-Dsecurity.manager}}). These are due in large part to missing {{permissions.xml}} files. Just adding these files to each test/arq deployment should cut the number of failures down dramatically. > Once this is done, individual test failures can be tackled. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 20:10:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 17 Mar 2017 20:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1058) Encapsulate logic to specify dynamic capability name resolution from a PathAddress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFCORE-1058. --------------------------------- Resolution: Done This is now done as part of work on WFCORE-2202 On RuntimeCapabilty you now have #setDynamicNameMapper(Function) Which species the mapping between path address and dynamic parts There is also new CompositeAttributeDependencyRecorder which takes this dynamic parts into account where recording requirements. When building attributes you have new variants to set capability reference #setCapabilityReference(String referencedCapability, AttributeDefinition ... dependantAttributes) and few others. > Encapsulate logic to specify dynamic capability name resolution from a PathAddress > ---------------------------------------------------------------------------------- > > Key: WFCORE-1058 > URL: https://issues.jboss.org/browse/WFCORE-1058 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > > One can create a capability whose dynamic name is not resolved using the value of the last element of a path address (e.g. using the value of a parent resource). In this case, the logic for generating the dynamic name need to be modified in multiple places. > # CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder.getDynamicDependentName(...) > # AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) > # AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...) > For reference, the clustering subsystems handle this via a custom abstraction: > https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main/java/org/jboss/as/clustering/controller/Capability.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 20:10:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 17 Mar 2017 20:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1058) Encapsulate logic to specify dynamic capability name resolution from a PathAddress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380503#comment-13380503 ] Tomaz Cerar edited comment on WFCORE-1058 at 3/17/17 8:09 PM: -------------------------------------------------------------- This is now done as part of work on WFCORE-2202 On RuntimeCapabilty you now have #setDynamicNameMapper(Function) Which defines the mapping between path address and dynamic parts There is also new CompositeAttributeDependencyRecorder which takes this dynamic parts into account where recording requirements. When building attributes you have new variants to set capability reference #setCapabilityReference(String referencedCapability, AttributeDefinition ... dependantAttributes) and few others. was (Author: ctomc): This is now done as part of work on WFCORE-2202 On RuntimeCapabilty you now have #setDynamicNameMapper(Function) Which species the mapping between path address and dynamic parts There is also new CompositeAttributeDependencyRecorder which takes this dynamic parts into account where recording requirements. When building attributes you have new variants to set capability reference #setCapabilityReference(String referencedCapability, AttributeDefinition ... dependantAttributes) and few others. > Encapsulate logic to specify dynamic capability name resolution from a PathAddress > ---------------------------------------------------------------------------------- > > Key: WFCORE-1058 > URL: https://issues.jboss.org/browse/WFCORE-1058 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > > One can create a capability whose dynamic name is not resolved using the value of the last element of a path address (e.g. using the value of a parent resource). In this case, the logic for generating the dynamic name need to be modified in multiple places. > # CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder.getDynamicDependentName(...) > # AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) > # AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...) > For reference, the clustering subsystems handle this via a custom abstraction: > https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main/java/org/jboss/as/clustering/controller/Capability.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 21:58:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 21:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-1220: ---------------------------------------- Assignee: (was: Brian Stansberry) > Try closing the channel if java.lang.Error prevents sending error responses to the client > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1220 > URL: https://issues.jboss.org/browse/WFCORE-1220 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > > Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue. > Options: > 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process. > If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process. > 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 22:22:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 22:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2533) DeploymentRolloutFailureTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2533: ------------------------------------- Component/s: Domain Management > DeploymentRolloutFailureTestCase fails with security manager in WF core > ----------------------------------------------------------------------- > > Key: WFCORE-2533 > URL: https://issues.jboss.org/browse/WFCORE-2533 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.domain.suites.DeploymentRolloutFailureTestCase#test* > {{cd testsuite/domain/}} > {{mvn test -Dtest=DeploymentRolloutFailureTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:main-three] 13:08:06,210 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "broken.jar" (runtime-name: "broken.jar") > [Server:main-three] 13:08:06,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service test.deployment.broken: org.jboss.msc.service.StartException in service test.deployment.broken: Failed to start service > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:main-three] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:main-three] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:main-three] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.broken.fail" "read")" in code source "(vfs:/content/broken.jar )" of "ModuleClassLoader for Module "deployment.broken.jar" from Service Module Loader") > [Server:main-three] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:main-three] at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:main-three] at java.lang.System.getProperty(System.java:443) [vm.jar:1.8.0] > [Server:main-three] at java.lang.System.getProperty(System.java:427) [vm.jar:1.8.0] > [Server:main-three] at java.lang.Boolean.getBoolean(Boolean.java:265) [rt.jar:1.8.0] > [Server:main-three] at org.jboss.as.test.integration.domain.deployment.broken.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:54) > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 22:23:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 22:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2534: ------------------------------------- Component/s: Domain Management > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 22:23:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 22:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2532) Some logging tests fail with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2532: ------------------------------------- Component/s: Logging > Some logging tests fail with security manager in WF core > -------------------------------------------------------- > > Key: WFCORE-2532 > URL: https://issues.jboss.org/browse/WFCORE-2532 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Test Suite > Reporter: Jan Tymel > > * *org.jboss.as.test.integration.logging.operations.CustomFormattersTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerOperationsTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.operations.Log4jCustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLog4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.LoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase* > * *org.jboss.as.test.integration.logging.profiles.NonExistingProfileTestCase* > * *org.jboss.as.test.integration.logging.syslog.SyslogHandlerTestCase* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=org.jboss.as.test.integration.logging.**.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging1.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging1.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging1.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging1.jar )\" of \"ModuleClassLoader for Module \"deployment.logging1.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging1.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.test.integration.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:168) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:314) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:304) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.testProfiles(LoggingProfilesTestCase.java:201 > {code} > * *org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase* > * *org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase* > * *org.jboss.as.test.manualmode.logging.PerDeployLoggingTestCase* > * *org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase* > * *org.jboss.as.test.manualmode.logging.SizeAppenderRestartTestCase* > * *org.jboss.as.test.manualmode.logging.SyslogIsNotAvailableDuringServerBootTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -Dtest=org.jboss.as.test.manualmode.logging.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging-test.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging-test.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging-test.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging-test.jar )\" of \"ModuleClassLoader for Module \"deployment.logging-test.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging-test.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.wildfly.core.testrunner.ServerController.deploy(ServerController.java:92) > at org.jboss.as.test.manualmode.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:197) > at org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase.startContainer(Log4jAppenderTestCase.java:93) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 22:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 22:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2535) ModuleResourceRootPathsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2535: ------------------------------------- Component/s: CLI > ModuleResourceRootPathsTestCase fails with security manager in WF core > ---------------------------------------------------------------------- > > Key: WFCORE-2535 > URL: https://issues.jboss.org/browse/WFCORE-2535 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.management.cli.modules.ModuleResourceRootPathsTestCase#testModules* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=ModuleResourceRootPathsTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:26:00,583 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."test-archive.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-archive.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "test-archive.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "jboss.bind.address" "read")" in code source "(vfs:/content/test-archive.war )" of "ModuleClassLoader for Module "deployment.test-archive.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) > at java.lang.System.getProperty(System.java:443) > at java.lang.System.getProperty(System.java:427) > at org.jboss.as.test.shared.TestSuiteEnvironment.getSystemProperty(TestSuiteEnvironment.java:50) > at org.jboss.as.test.shared.TestSuiteEnvironment.getHttpAddress(TestSuiteEnvironment.java:173) > at org.wildfly.test.undertow.UndertowServiceActivator.getAddress(UndertowServiceActivator.java:100) > at org.wildfly.test.undertow.UndertowServiceActivator.activate(UndertowServiceActivator.java:66) > at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 22:39:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 22:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1762) Missing dependency should be triggering rollback of the deployment operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1762: ------------------------------------- Component/s: Domain Management > Missing dependency should be triggering rollback of the deployment operation > ---------------------------------------------------------------------------- > > Key: WFCORE-1762 > URL: https://issues.jboss.org/browse/WFCORE-1762 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Martin Stefanko > > The removal of the deployment which is a dependency for other resources makes these dependent resources unusable. The deployment operation should not be completed in such conditions. > The information about the missing dependencies is now currently logged after the removal by the ContainerStateMonitor class. > Example: > {code}INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment postgresql-9.4.1208.jar (runtime-name: postgresql-9.4.1208.jar) in 61ms > INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0009: Undeployed "postgresql-9.4.1208.jar" (runtime-name: "postgresql-9.4.1208.jar") > INFO [org.jboss.as.repository] (ServerService Thread Pool -- 65) WFLYDR0002: Content removed from location /home/mjurc/testing/eap/7.0.0/jboss-eap-7.0/standalone/data/content/5c/7e80698b80a5045fe64daa67426051bbd16a56/content > INFO [org.jboss.as.controller] (ServerService Thread Pool -- 65) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.jdbc-driver.postgresql-9_4_1208_jar (missing) dependents: [service jboss.driver-demander.java:/PostgresDS, service org.wildfly.data-source.PostgresDS] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 23:30:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 23:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1762) Missing dependency should be triggering rollback of the deployment operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-1762: ---------------------------------------- Assignee: Brian Stansberry > Missing dependency should be triggering rollback of the deployment operation > ---------------------------------------------------------------------------- > > Key: WFCORE-1762 > URL: https://issues.jboss.org/browse/WFCORE-1762 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Martin Stefanko > Assignee: Brian Stansberry > > The removal of the deployment which is a dependency for other resources makes these dependent resources unusable. The deployment operation should not be completed in such conditions. > The information about the missing dependencies is now currently logged after the removal by the ContainerStateMonitor class. > Example: > {code}INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment postgresql-9.4.1208.jar (runtime-name: postgresql-9.4.1208.jar) in 61ms > INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0009: Undeployed "postgresql-9.4.1208.jar" (runtime-name: "postgresql-9.4.1208.jar") > INFO [org.jboss.as.repository] (ServerService Thread Pool -- 65) WFLYDR0002: Content removed from location /home/mjurc/testing/eap/7.0.0/jboss-eap-7.0/standalone/data/content/5c/7e80698b80a5045fe64daa67426051bbd16a56/content > INFO [org.jboss.as.controller] (ServerService Thread Pool -- 65) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.jdbc-driver.postgresql-9_4_1208_jar (missing) dependents: [service jboss.driver-demander.java:/PostgresDS, service org.wildfly.data-source.PostgresDS] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 17 23:30:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 17 Mar 2017 23:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1762) Missing dependency should be triggering rollback of the deployment operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380506#comment-13380506 ] Brian Stansberry commented on WFCORE-1762: ------------------------------------------ The specific problem here is the no-longer-available service is not one that was directly removed by the management op. Instead it's a child service of the one the op removed (a great-great-great grandchild really). The result of that is the OperationContext doesn't know how to associate the missing dependency with the step that caused the problem. I don't know how to make that association. If the problem op is a step in a composite it's not possible to identify the specific step in the composite that broke things. But it's possible to detect that the overall op has triggered a missing dependency and that no step has been reported as problematic. If that happens, a failure message can be associated with the main operation response. If its a composite the particular step won't get the failure description, but the overall op will and hopefully the user can figure out the problem step. This kind of thing mostly can happen when something outside a deployment depends on a service created when the deployment is deployed. So, inter-deployment dependencies, or like here a container service depending on a deployment service. The management op knows about root deployment service. But it's a great-great-great grandchild of that root deployment service that becomes the missing dependency. > Missing dependency should be triggering rollback of the deployment operation > ---------------------------------------------------------------------------- > > Key: WFCORE-1762 > URL: https://issues.jboss.org/browse/WFCORE-1762 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Martin Stefanko > > The removal of the deployment which is a dependency for other resources makes these dependent resources unusable. The deployment operation should not be completed in such conditions. > The information about the missing dependencies is now currently logged after the removal by the ContainerStateMonitor class. > Example: > {code}INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment postgresql-9.4.1208.jar (runtime-name: postgresql-9.4.1208.jar) in 61ms > INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0009: Undeployed "postgresql-9.4.1208.jar" (runtime-name: "postgresql-9.4.1208.jar") > INFO [org.jboss.as.repository] (ServerService Thread Pool -- 65) WFLYDR0002: Content removed from location /home/mjurc/testing/eap/7.0.0/jboss-eap-7.0/standalone/data/content/5c/7e80698b80a5045fe64daa67426051bbd16a56/content > INFO [org.jboss.as.controller] (ServerService Thread Pool -- 65) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.jdbc-driver.postgresql-9_4_1208_jar (missing) dependents: [service jboss.driver-demander.java:/PostgresDS, service org.wildfly.data-source.PostgresDS] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 18 11:33:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sat, 18 Mar 2017 11:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380528#comment-13380528 ] Brian Stansberry commented on WFCORE-2351: ------------------------------------------ WFCORE-1762 relates to my most recent comment on WFCORE-2351 as the WFCORE-1762 change will ensure that an ERROR is logged if an op introduces MSC failures or missing services and none of the other op verification techniques detect that. One of the benefits of the current ContainerStateMonitor INFO level logging is it would at least produce some output in that kind of situation, but that benefit would now be covered in a better way by WFCORE-1762. That makes me comfortable with having the ContainerStateMonitor INFO level logging only log the final status at the end of the op, after any rollback work. Which means in most cases no logging at all. With that I also think the ContainerStateMonitor should be a WARN if the report shows any problems, and INFO otherwise. If the final result of the op is MSC is left with installed services that failed or having missing dependencies, that should be a WARN. > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2351 > URL: https://issues.jboss.org/browse/WFCORE-2351 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 05:13:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Sun, 19 Mar 2017 05:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1014) Elytron auth method misconfiguration not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina moved WFCORE-2432 to ELY-1014: ----------------------------------------- Project: WildFly Elytron (was: WildFly Core) Key: ELY-1014 (was: WFCORE-2432) Component/s: Authentication Mechanisms (was: Security) > Elytron auth method misconfiguration not logged > ----------------------------------------------- > > Key: ELY-1014 > URL: https://issues.jboss.org/browse/ELY-1014 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Labels: user_experience > > When deployment is configured to be secured with DIGEST, but {{http-authentication-factory}} does not list DIGEST mechanism, user is not informed about misconfiguration. Even when TRACE logging is turned on. When user tries to access app 403 http code is returned and Forbidden is shown in browser. I would expect browser dialog to appear to allow user provide credentials (401 http status code). > {code:title=web.xml} > > DIGEST > ApplicaitonRealm > > {code} > {code:title=standalone-elytron.xml} > > > > > > > > > {code} > This applies globally to all authentication mechanisms, not only DIGEST. > Could elytron handle misconfiguration: > * either fail during deploying application as deployment requirement can't be satisfy > * or provide reasonable elytron defaults of missing mechanism configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 11:54:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 19 Mar 2017 11:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2558) If an op fails but isn't rolled back, the response doesn't report non-rollback In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2558: ---------------------------------------- Summary: If an op fails but isn't rolled back, the response doesn't report non-rollback Key: WFCORE-2558 URL: https://issues.jboss.org/browse/WFCORE-2558 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry If an op rolls back, the response includes "rolled-back"=>true. But if a failure occurs but the op doesn't roll back (because the rollback-on-runtime-failure operation header was set to false) there is no "rolled-back"=>false in the response. The effect of the operation is therefore unclear to the user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 13:41:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sun, 19 Mar 2017 13:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8403) Update default host-slave.xml configurations to use username $local In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8403: -------------------------------------- Summary: Update default host-slave.xml configurations to use username $local Key: WFLY-8403 URL: https://issues.jboss.org/browse/WFLY-8403 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 19:33:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 19 Mar 2017 19:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8404) Http invocation security is not settup up the identity correctly In-Reply-To: References: Message-ID: Stuart Douglas created WFLY-8404: ------------------------------------ Summary: Http invocation security is not settup up the identity correctly Key: WFLY-8404 URL: https://issues.jboss.org/browse/WFLY-8404 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 19:33:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 19 Mar 2017 19:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8404) Http invocation security is not settup up the identity correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas reassigned WFLY-8404: ------------------------------------ Assignee: Stuart Douglas (was: Jason Greene) > Http invocation security is not settup up the identity correctly > ---------------------------------------------------------------- > > Key: WFLY-8404 > URL: https://issues.jboss.org/browse/WFLY-8404 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 19:33:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 19 Mar 2017 19:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8404) Http invocation security is not settup up the identity correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas updated WFLY-8404: --------------------------------- Component/s: EJB > Http invocation security is not settup up the identity correctly > ---------------------------------------------------------------- > > Key: WFLY-8404 > URL: https://issues.jboss.org/browse/WFLY-8404 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 20:39:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 19 Mar 2017 20:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8405) Http invocation security is not settup up the identity correctly In-Reply-To: References: Message-ID: Stuart Douglas created WFLY-8405: ------------------------------------ Summary: Http invocation security is not settup up the identity correctly Key: WFLY-8405 URL: https://issues.jboss.org/browse/WFLY-8405 Project: WildFly Issue Type: Bug Components: EJB Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 20:42:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 19 Mar 2017 20:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8404) Http invocation security is not setting up the identity correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas updated WFLY-8404: --------------------------------- Summary: Http invocation security is not setting up the identity correctly (was: Http invocation security is not settup up the identity correctly) > Http invocation security is not setting up the identity correctly > ----------------------------------------------------------------- > > Key: WFLY-8404 > URL: https://issues.jboss.org/browse/WFLY-8404 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 20:53:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Sun, 19 Mar 2017 20:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1486) Add non-breakable space \u00A0 to the list of white spaces in FEEL lexer In-Reply-To: References: Message-ID: Edson Tirelli created DROOLS-1486: ------------------------------------- Summary: Add non-breakable space \u00A0 to the list of white spaces in FEEL lexer Key: DROOLS-1486 URL: https://issues.jboss.org/browse/DROOLS-1486 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta7 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.0.0.Final Sometime the web editors replace regular whitespaces by the non-breakable white space character \u00A0 and that breaks the FEEL lexer. Add this character to the list of whitespaces characters in the lexer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 19 22:29:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Sun, 19 Mar 2017 22:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7692) http2-* attributes def values in Undertow for listeners and mod-cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chao Wang updated WFLY-7692: ---------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9430, https://github.com/wildfly/wildfly/pull/9829 (was: https://github.com/wildfly/wildfly/pull/9430) > http2-* attributes def values in Undertow for listeners and mod-cluster > ----------------------------------------------------------------------- > > Key: WFLY-7692 > URL: https://issues.jboss.org/browse/WFLY-7692 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > For {{http-listener}}, {{https-listener}} and {{mod-cluster}} filter in Undertow subsystem, there are some http2 related attributes: > {code} > "http2-header-table-size" => { > "type" => INT, > "description" => "The size of the header table used for HPACK compression, in bytes. This amount of memory will be allocated per connection for compression. Larger values use more memory but may give better compression.", > "expressions-allowed" => true, > "nillable" => true, > "unit" => "BYTES", > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > "http2-initial-window-size" => { > "type" => INT, > "description" => "The flow control window size that controls how quickly the client can send data to the server", > "expressions-allowed" => true, > "nillable" => true, > "unit" => "BYTES", > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > "http2-max-concurrent-streams" => { > "type" => INT, > "description" => "The maximum number of HTTP/2 streams that can be active at any time on a single connection", > "expressions-allowed" => true, > "nillable" => true, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > "http2-max-frame-size" => { > "type" => INT, > "description" => "The max HTTP/2 frame size", > "expressions-allowed" => true, > "nillable" => true, > "unit" => "BYTES", > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > "http2-max-header-list-size" => { > "type" => INT, > "description" => "The maximum size of request headers the server is prepared to accept", > "expressions-allowed" => true, > "nillable" => true, > "unit" => "BYTES", > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {code} > By default, all of these attributes are set as undefined. This might be reasonable e.g. for {{http2-max-concurrent-streams}} which in that case might mean that actual maximal value is not restricted anyhow (is it actually true?). But for other attributes this might be misleading for user as he actually does not know what is real default and used value (e.g. for {{http2-initial-window-size}} is used 65535) in such situation. Thus I think that we should provide some default values here so user knows what values are used. > EDIT: also please pay some attention to a {{max-ajp-packet-size}} attribute that is available in {{ajp-listener}} and {{mod-cluster}} filter - there is no default value set here (undefined by default although I believe some default is actually used - 8192?) and also no units are specified in resource-description for that one (bytes, I believe, should that be). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 04:31:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Mon, 20 Mar 2017 04:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-945) User names in Elytron FileSystemRealm are not case sensitive on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski reassigned ELY-945: -------------------------------------- Assignee: ehsavoie Hugonnet (was: Bartosz Baranowski) > User names in Elytron FileSystemRealm are not case sensitive on Windows > ----------------------------------------------------------------------- > > Key: ELY-945 > URL: https://issues.jboss.org/browse/ELY-945 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Blocker > > User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}} > This is IMO a security issue. And it also affects platform certifications. > If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 04:37:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Mon, 20 Mar 2017 04:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2559) caching-realm with ldap-realm cannot be added when LDAP is unreachable In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2559: ------------------------------------ Summary: caching-realm with ldap-realm cannot be added when LDAP is unreachable Key: WFCORE-2559 URL: https://issues.jboss.org/browse/WFCORE-2559 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In case when caching-realm is used together with ldap-realm and LDAP server (which is used by that ldap-realm) is unreachable, then caching-realm cannot be added. This issue also causes that this realm service is not correctly started when server is started. It means that in case when LDAP server is unreachable during starting application server, then this realm will not work until it will be reloaded again and LDAP will be reachable. Following exception occurs for CLI command: {code} /subsystem=elytron/caching-realm=some-cache-realm:add(realm=some-ldap-realm) { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] Caused by: java.net.ConnectException: Connection refused"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"] }, "rolled-back" => true } {code} Following exception occurs in server log when mentioned above CLI command is executed: {code} ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.some-cache-realm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) 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.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:153) at org.wildfly.security.auth.realm.CachingSecurityRealm.(CachingSecurityRealm.java:60) at org.wildfly.security.auth.realm.CachingModifiableSecurityRealm.(CachingModifiableSecurityRealm.java:53) at org.wildfly.extension.elytron.CachingRealmDefinition$RealmAddHandler.lambda$createService$0(CachingRealmDefinition.java:143) at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) ... 3 more Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:187) at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:149) ... 9 more Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] at com.sun.jndi.ldap.Connection.(Connection.java:216) at com.sun.jndi.ldap.LdapClient.(LdapClient.java:137) at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746) at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:319) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116) at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:154) at org.jboss.as.naming.InitialContext.(InitialContext.java:91) at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at javax.naming.InitialContext.init(InitialContext.java:244) at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:154) at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:442) at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:356) at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:227) at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:462) at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:185) ... 10 more Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350) at com.sun.jndi.ldap.Connection.(Connection.java:203) ... 32 more 09:26:07,954 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("caching-realm" => "some-cache-realm") ]) - failure description: { "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] Caused by: java.net.ConnectException: Connection refused"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"] } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 04:38:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Mon, 20 Mar 2017 04:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2559) caching-realm with ldap-realm cannot be added when LDAP is unreachable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2559: --------------------------------- Affects Version/s: 3.0.0.Beta9 > caching-realm with ldap-realm cannot be added when LDAP is unreachable > ---------------------------------------------------------------------- > > Key: WFCORE-2559 > URL: https://issues.jboss.org/browse/WFCORE-2559 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In case when caching-realm is used together with ldap-realm and LDAP server (which is used by that ldap-realm) is unreachable, then caching-realm cannot be added. > This issue also causes that this realm service is not correctly started when server is started. It means that in case when LDAP server is unreachable during starting application server, then this realm will not work until it will be reloaded again and LDAP will be reachable. > Following exception occurs for CLI command: > {code} > /subsystem=elytron/caching-realm=some-cache-realm:add(realm=some-ldap-realm) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service > Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener > Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context > Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] > Caused by: java.net.ConnectException: Connection refused"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"] > }, > "rolled-back" => true > } > {code} > Following exception occurs in server log when mentioned above CLI command is executed: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.some-cache-realm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:153) > at org.wildfly.security.auth.realm.CachingSecurityRealm.(CachingSecurityRealm.java:60) > at org.wildfly.security.auth.realm.CachingModifiableSecurityRealm.(CachingModifiableSecurityRealm.java:53) > at org.wildfly.extension.elytron.CachingRealmDefinition$RealmAddHandler.lambda$createService$0(CachingRealmDefinition.java:143) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:187) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:149) > ... 9 more > Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] > at com.sun.jndi.ldap.Connection.(Connection.java:216) > at com.sun.jndi.ldap.LdapClient.(LdapClient.java:137) > at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746) > at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) > at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:154) > at org.jboss.as.naming.InitialContext.(InitialContext.java:91) > at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > at javax.naming.InitialContext.init(InitialContext.java:244) > at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:442) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:356) > at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:227) > at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:462) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:185) > ... 10 more > Caused by: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350) > at com.sun.jndi.ldap.Connection.(Connection.java:203) > ... 32 more > 09:26:07,954 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("caching-realm" => "some-cache-realm") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service > Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener > Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context > Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused] > Caused by: java.net.ConnectException: Connection refused"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"] > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 05:46:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Mon, 20 Mar 2017 05:46:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380697#comment-13380697 ] Chao Wang commented on WFCORE-2351: ----------------------------------- Thank your for all the detailed analysis above. In your change, you checked the controller state is not REMOVED before adding any missing dependency. But there are other states like STOPPING and START_FAILED, I guess they are not considered as reasonable state in this particular missing dependency lookup, it's thus safe to only compare with REMOVED here? > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2351 > URL: https://issues.jboss.org/browse/WFCORE-2351 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 05:48:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Mon, 20 Mar 2017 05:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-71) Test Hawkular Java Agent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-71: ---------------------------------------- Assignee: Hayk Hovsepyan (was: Michael Foley) > Test Hawkular Java Agent > ------------------------ > > Key: HAWKULARQE-71 > URL: https://issues.jboss.org/browse/HAWKULARQE-71 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Minor > > There is a new Java Agent (HJA) that you can run in any JVM (including > but not limited to EAP-based projects). You do so by passing in a > "-javaagent" command line option to your JVM (e.g. java > -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar > ...yadda...). There are two additional properties you must set in > standalone.conf if you want to run it inside an EAP JVM. The README will > have the details. > This new HJA is configured with a yaml file that largely mimics all the > standalone.xml data that HWFA has. There is no ${x} support in the YAML > file right now. > This new HJA can talk to any EAP or WildFly server over the DMR management > API. It can do deployments to your EAP/WildFly servers and monitoring of > EAP/WildFly subsystems just like HWFA can. > This new HJA can talk to any JMX server just like HWFA can (it will talk to > the local MBeanServer or, if remotely monitoring a JMX server, it will talk > to it over Jolokia/REST API). > This new HJA can NOT run directly inside of a Host Controller due to > https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA > externally in its own JVM (e.g. java -jar hawkular-javaagent.jar > config=config.yaml) and have its config.yaml point to a remote Host > Controller and you'll get the same functionality. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 05:55:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Mon, 20 Mar 2017 05:55:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2549: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta11) > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta10 > > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 06:06:01 2017 From: issues at jboss.org (Martin Stefanko (JIRA)) Date: Mon, 20 Mar 2017 06:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8406) Referencing credential store from mail subsystem without alias results in returned password "undefined" In-Reply-To: References: Message-ID: Martin Stefanko created WFLY-8406: ------------------------------------- Summary: Referencing credential store from mail subsystem without alias results in returned password "undefined" Key: WFLY-8406 URL: https://issues.jboss.org/browse/WFLY-8406 Project: WildFly Issue Type: Bug Components: Mail Affects Versions: 10.1.0.Final Reporter: Martin Stefanko Assignee: Martin Stefanko When using credential-reference pointing only to store without password, it results in using password "undefined" As providing password which is incorrect one is very bad from security point of view, marking as blocker for GA. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 06:15:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 20 Mar 2017 06:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7337) Introduce an authorization SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380720#comment-13380720 ] Amos Feng commented on WFLY-7337: --------------------------------- [~dmlloyd] can we close this issue with "Won't Do" ? are you satisfied that we do not introduce these authorization functions into the narayana ? > Introduce an authorization SPI > ------------------------------ > > Key: WFLY-7337 > URL: https://issues.jboss.org/browse/WFLY-7337 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 07:09:00 2017 From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=) Date: Mon, 20 Mar 2017 07:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1363) revapi-maven-plugin forks exutions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380751#comment-13380751 ] Mari?n Macik commented on DROOLS-1363: -------------------------------------- Yes, it is fixed. Marking as resolved. > revapi-maven-plugin forks exutions > ---------------------------------- > > Key: DROOLS-1363 > URL: https://issues.jboss.org/browse/DROOLS-1363 > Project: Drools > Issue Type: Bug > Components: build > Reporter: Petr ?irok? > Assignee: Mari?n Macik > > Revapi Maven plugin, as used in kie-api, forks the exeuctions causing almost the whole build to be executed three times. This needs to be fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 07:09:01 2017 From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=) Date: Mon, 20 Mar 2017 07:09:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1363) revapi-maven-plugin forks exutions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mari?n Macik resolved DROOLS-1363. ---------------------------------- Resolution: Done > revapi-maven-plugin forks exutions > ---------------------------------- > > Key: DROOLS-1363 > URL: https://issues.jboss.org/browse/DROOLS-1363 > Project: Drools > Issue Type: Bug > Components: build > Reporter: Petr ?irok? > Assignee: Mari?n Macik > > Revapi Maven plugin, as used in kie-api, forks the exeuctions causing almost the whole build to be executed three times. This needs to be fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 07:38:01 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Mon, 20 Mar 2017 07:38:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-46) Agent starts the agentservice when an agent config is changed. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-46: ---------------------------------------- Assignee: Hayk Hovsepyan (was: Michael Foley) > Agent starts the agentservice when an agent config is changed. > -------------------------------------------------------------- > > Key: HAWKULARQE-46 > URL: https://issues.jboss.org/browse/HAWKULARQE-46 > Project: Hawkular QE > Issue Type: Task > Environment: From hrupp Status 2/23/2017 - Agent Release 0.28 > Major change to wildfly agent internals - it now restarts the agent > service when an agent config is changed. > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 07:56:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 20 Mar 2017 07:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1343) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: Ingo Weiss created JBJCA-1343: --------------------------------- Summary: Account for additional DB2 FATAL connection errors Key: JBJCA-1343 URL: https://issues.jboss.org/browse/JBJCA-1343 Project: IronJacamar Issue Type: Enhancement Components: Validator Reporter: Ingo Weiss Assignee: Ingo Weiss Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 07:59:00 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Mon, 20 Mar 2017 07:59:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1487) Parallel agenda cycles itself or throws NPE In-Reply-To: References: Message-ID: Tibor Zim?nyi created DROOLS-1487: ------------------------------------- Summary: Parallel agenda cycles itself or throws NPE Key: DROOLS-1487 URL: https://issues.jboss.org/browse/DROOLS-1487 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.0.0.Beta7 Reporter: Tibor Zim?nyi Assignee: Mario Fusco Running AdvOperatorsExpertBenchmark benchmarks from our kie-benchmarks suite with parallel agenda option, the benchmark either cycles itself or throws NPE [1]. I created a "reproducer" here[2]. Be aware that this is failing nondeterministically, so with high probability it is a nasty race condition. I tried to debug this a bit and this is the output of some variables that is available on this line [3]: Returned fire count: 0 Head: null Group: AgendaGroup 'MAIN' Group is auto deactivate: true Limit reached: false IsInternalFire: false IsFiring: true [1] http://pastebin.com/sjLjQwgX [2] https://github.com/kiegroup/kie-benchmarks/pull/8/files [3] https://github.com/kiegroup/drools/blob/3038a1b9287978069bcb2765dc684f69683465a4/drools-core/src/main/java/org/drools/core/common/DefaultAgenda.java#L1084 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 08:33:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Mon, 20 Mar 2017 08:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1488) Fix JSONMarshaller.writeMap() check for double-wrapping for map values In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1488: -------------------------------------- Summary: Fix JSONMarshaller.writeMap() check for double-wrapping for map values Key: DROOLS-1488 URL: https://issues.jboss.org/browse/DROOLS-1488 Project: Drools Issue Type: Bug Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor The fix is the same as highlighted in the [closed PR #856|https://github.com/kiegroup/droolsjbpm-integration/pull/856]. While the originally proposed fix is working on serialization, it posed some issues during de-serialization side, suggesting the correction cannot be a blind-fix as per original [closed PR #856|https://github.com/kiegroup/droolsjbpm-integration/pull/856]. It is suggested to investigate further with a comprehensive test, including serialization and deserialization. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 09:15:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Mon, 20 Mar 2017 09:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek closed WFCORE-2046. ------------------------------- Fix Version/s: (was: 3.0.0.Beta11) Resolution: Won't Fix Aligning the status with JBEAP-7523 - setting to "Won't fix", as the presented fix is not on EAP/WildFly side, but in on IBM java side. IBM Java users who hit this issue should upgrade the Java SDK to (at least) 8.0 SR4 FP1. > KeyManager synchronization issue when using IBM JDK > --------------------------------------------------- > > Key: WFCORE-2046 > URL: https://issues.jboss.org/browse/WFCORE-2046 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: test-app-ibm-jdk-keymanager-sync.zip > > > We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords. > As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines. > Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}). > The workflow: > # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}} > # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}} > # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore. > *Possible workaround* > We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 09:34:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 09:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Regression Testing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380865#comment-13380865 ] Matt Mahoney commented on HAWKULARQE-63: ---------------------------------------- >From JMazz: The only thing added post-0.28.0.Final was this Java Agent stuff. The Wildfly Agent (the thing you've been testing with) hasn't changed - it should work the same as before. The Java Agent that was introduced should work the same as that WildFly agent except: 1) it is installed via the -javaagent option when launching a JVM, not injected in standalone.xml within WildFly itself 2) it uses its own YAML configuration file rather than XML in the standalone.xml (thought the yaml setting names mimic the XML element/attribute names - e.g. metric-set-dmr, local-dmr, etc). Example yaml files are found here (see the real-config*.yaml ones): https://github.com/hawkular/hawkular-agent/tree/master/hawkular-javaagent/src/test/resources 3) You cannot run Java Agent directly in a Host Controller - but since domain mode isn't supported in this Middleware Manager stuff, I doubt you care about that. Really, other than that, this Java Agent should behave just like the WildFly Agent. That is in theory - in actuality, we'll need testing to find the places that are broken But the pieces that are going to be broke are probably not in the agent directly, but in the Middleware Manager UI that hardcoded some things it expects when the agent is deployed as a WildFly subsystem. We would need to fix those kinds of things. > Hawkular Agent - Regression Testing > ----------------------------------- > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 09:41:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 20 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8406) Referencing credential store from mail subsystem without alias results in returned password "undefined" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8406: ----------------------------------- Affects Version/s: (was: 10.1.0.Final) > Referencing credential store from mail subsystem without alias results in returned password "undefined" > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-8406 > URL: https://issues.jboss.org/browse/WFLY-8406 > Project: WildFly > Issue Type: Bug > Components: Mail > Reporter: Martin Stefanko > Assignee: Martin Stefanko > > When using credential-reference pointing only to store without password, it results in using password "undefined" > As providing password which is incorrect one is very bad from security point of view, marking as blocker for GA. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 09:42:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 09:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-63: ----------------------------------- Summary: Hawkular Agent - Changes (Non JMANs) (was: Hawkular Agent - Regression Testing) > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 09:43:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 09:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380876#comment-13380876 ] Matt Mahoney commented on HAWKULARQE-63: ---------------------------------------- On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli wrote: Just released Hawkular Java Agent 0.29.1.Final that contains a new feature. To support deploying Java Agent within containers (though this feature isn't restricted to that use-case), you can configure many settings in the Java Agent YAML config with ${x} expressions (similar to how HWFA can be configured in standalone.xml). It supports getting values from system properties, environment variables, with default values optionally defined. The following expressions are supported - hopefully this is self-explanatory: ${some.system.property} ${some.system.property:a-default-value} ${ENV~SOME_ENV_VAR} ${ENV~SOME_ENV_VAR:a-default-value} Not all properties support expressions (most don't need them) but properties that define things like hosts, ports, urls, passwords, filepaths, do support expressions. If I missed any, or if you'd like a property to support expressions that does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/projects/HWKAGENT > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:17:00 2017 From: issues at jboss.org (Pierfrancesco Girolami (JIRA)) Date: Mon, 20 Mar 2017 10:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (AS7-995) Exploded EAR deployment error - java.util.zip.ZipException: error in opening zip file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13380931#comment-13380931 ] Pierfrancesco Girolami commented on AS7-995: -------------------------------------------- That's as Peter said. Accidentally an empy jar was included in ear lib directory so this generate the java.util.zip.ZipException. Thanks. > Exploded EAR deployment error - java.util.zip.ZipException: error in opening zip file > ------------------------------------------------------------------------------------- > > Key: AS7-995 > URL: https://issues.jboss.org/browse/AS7-995 > Project: Application Server 7 > Issue Type: Bug > Components: VFS > Affects Versions: 7.0.0.Beta3 > Environment: JBoss Tools 3.3-M6 (Eclipse Indigo, Win7 32-bit), Maven 3.0.3 application > Reporter: Peter Bocak > Labels: ear, maven, vfs > Fix For: No Release > > Attachments: deployments.zip > > > Deployment of EAR application (ejb module, JSF war module, 2 jar libraries) fails with ZipException error on JBoss AS Beta 3 and Beta-4-SNAPSHOT using standalone server with exploded archives. Application is published by JBoss Tools 3.3.M6. Content of "\jboss-7.0.0.Beta3\standalone\deployments" directory included in attachment. > 15:20:17,611 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "SNapplication-0.0.1-SNAPSHOT.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_22] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_22] > at java.lang.Thread.run(Unknown Source) [:1.6.0_22] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to process children for EAR ["/C:/Dev/jboss-7.0.0.Beta3/bin/content/SNapplication-0.0.1-SNAPSHOT.ear"] > at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:211) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102) > ... 4 more > Caused by: java.util.zip.ZipException: error in opening zip file > at java.util.zip.ZipFile.open(Native Method) [:1.6.0_22] > at java.util.zip.ZipFile.(Unknown Source) [:1.6.0_22] > at java.util.jar.JarFile.(Unknown Source) [:1.6.0_22] > at java.util.jar.JarFile.(Unknown Source) [:1.6.0_22] > at org.jboss.vfs.spi.JavaZipFileSystem.(JavaZipFileSystem.java:94) > at org.jboss.vfs.spi.JavaZipFileSystem.(JavaZipFileSystem.java:80) > at org.jboss.vfs.VFS.mountZip(VFS.java:428) > at org.jboss.vfs.VFS.mountZip(VFS.java:454) > at org.jboss.as.ee.structure.EarStructureProcessor.mount(EarStructureProcessor.java:216) > at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:124) > ... 5 more > 15:20:17,615 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report > Services which failed to start: > service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "SNapplication-0.0.1-SNAPSHOT.ear" > ------------------------------------------------------------------------------------------------------------------ > EAR structure: > \business-0.0.1-SNAPSHOT.jar > \userweb-0.0.1-SNAPSHOT.war > \META-INF\application.xml > \META-INF\jboss-app.xml > \META-INF\MANIFEST.MF > \lib\domain-0.0.1-SNAPSHOT.jar > \lib\eclipselink-2.2.0.jar > \lib\javax.persistence-2.0.3.jar > \lib\wsclients-0.0.1-SNAPSHOT.jar > pom.xml: > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > application > ear > SMS Notify Application > > sk.arsnova.sn > assembly > 0.0.1-SNAPSHOT > > > UTF-8 > > > > ${project.groupId} > business > ${project.version} > ejb > compile > > > ${project.groupId} > domain > ${project.version} > jar > compile > > > ${project.groupId} > userweb > ${project.version} > war > compile > > > ${project.groupId} > wsclients > ${project.version} > jar > compile > > > > > > org.apache.maven.plugins > maven-compiler-plugin > 2.3.2 > > 1.6 > 1.6 > > > > org.apache.maven.plugins > maven-ear-plugin > 2.5 > > 6 > lib > > > > > > application.xml: > > > application > > business-0.0.1-SNAPSHOT.jar > > > > userweb-0.0.1-SNAPSHOT.war > /userweb > > > lib > > Unexploded EAR deploys succesfully. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:32:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 20 Mar 2017 10:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1015) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties In-Reply-To: References: Message-ID: Tomaz Cerar created ELY-1015: -------------------------------- Summary: AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties Key: ELY-1015 URL: https://issues.jboss.org/browse/ELY-1015 Project: WildFly Elytron Issue Type: Bug Reporter: Tomaz Cerar Assignee: Darran Lofthouse jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration but it is not wired to actual client configuration. As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:42:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 20 Mar 2017 10:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8407) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved ELY-1015 to WFLY-8407: --------------------------------------------- Project: WildFly (was: WildFly Elytron) Key: WFLY-8407 (was: ELY-1015) > AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-8407 > URL: https://issues.jboss.org/browse/WFLY-8407 > Project: WildFly > Issue Type: Bug > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration > but it is not wired to actual client configuration. > As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:42:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 20 Mar 2017 10:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8407) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8407: ----------------------------------- Component/s: EJB > AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-8407 > URL: https://issues.jboss.org/browse/WFLY-8407 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration > but it is not wired to actual client configuration. > As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:45:01 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Mon, 20 Mar 2017 10:45:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8408) Upgrade HAL to 2.9.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-8408: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9799) > Upgrade HAL to 2.9.5.Final > -------------------------- > > Key: WFLY-8408 > URL: https://issues.jboss.org/browse/WFLY-8408 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:45:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Mon, 20 Mar 2017 10:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8408) Upgrade HAL to 2.9.5.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-8408: --------------------------------- Summary: Upgrade HAL to 2.9.5.Final Key: WFLY-8408 URL: https://issues.jboss.org/browse/WFLY-8408 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 10:53:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Mon, 20 Mar 2017 10:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2560) User names in Elytron FileSystemRealm are not case sensitive on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet moved JBEAP-9698 to WFCORE-2560: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2560 (was: JBEAP-9698) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta9 (was: 7.1.0.DR12) > User names in Elytron FileSystemRealm are not case sensitive on Windows > ----------------------------------------------------------------------- > > Key: WFCORE-2560 > URL: https://issues.jboss.org/browse/WFCORE-2560 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Labels: filesystem-realm, security-realm, windows > > User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}} > This is IMO a security issue. And it also affects platform certifications. > If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:04:00 2017 From: issues at jboss.org (Martin Cimbalek (JIRA)) Date: Mon, 20 Mar 2017 11:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1489) Repeated fireAllRules() causes firing rules multiple times when using OOPath + JPA In-Reply-To: References: Message-ID: Martin Cimbalek created DROOLS-1489: --------------------------------------- Summary: Repeated fireAllRules() causes firing rules multiple times when using OOPath + JPA Key: DROOLS-1489 URL: https://issues.jboss.org/browse/DROOLS-1489 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.0.0.Beta8 Reporter: Martin Cimbalek Assignee: Mario Fusco Repeated calling fireAllRules causes firing rules repeatedely when using OOPath in combination with JPA persistence even when facts were not modified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:16:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 20 Mar 2017 11:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1507) Expose features currently provided by ModelController via capabilities usable by extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1507: ------------------------------------- Description: -A server installs ServerService while an HC installs DomainModelControllerService, under different service names but both of which implement Service. To make it easier for subsystems that want ModelController access to work on both a server and an HC, we should create a capability with service type ModelController and have both processes use it.- Extensions may have a need to create an internal ModelControllerClient or to register notification handlers. Currently this is done by looking up the ModelController via its internal service name but: 1) ModelController exposes methods that should not be available to extensions 2) Accessing services should be via a capability. So, we need to expose capabilities for these functions. was:A server installs ServerService while an HC installs DomainModelControllerService, under different service names but both of which implement Service. To make it easier for subsystems that want ModelController access to work on both a server and an HC, we should create a capability with service type ModelController and have both processes use it. > Expose features currently provided by ModelController via capabilities usable by extensions > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1507 > URL: https://issues.jboss.org/browse/WFCORE-1507 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > -A server installs ServerService while an HC installs DomainModelControllerService, under different service names but both of which implement Service. To make it easier for subsystems that want ModelController access to work on both a server and an HC, we should create a capability with service type ModelController and have both processes use it.- > Extensions may have a need to create an internal ModelControllerClient or to register notification handlers. Currently this is done by looking up the ModelController via its internal service name but: > 1) ModelController exposes methods that should not be available to extensions > 2) Accessing services should be via a capability. > So, we need to expose capabilities for these functions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:29:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 11:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-46) Agent starts the agentservice when an agent config is changed. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381015#comment-13381015 ] Matt Mahoney commented on HAWKULARQE-46: ---------------------------------------- There is no developer doc on Agent changes, thus rolled up emails on the subject. JMazz is the go-to developer for questions on the changes. https://mojo.redhat.com/docs/DOC-1131931 > Agent starts the agentservice when an agent config is changed. > -------------------------------------------------------------- > > Key: HAWKULARQE-46 > URL: https://issues.jboss.org/browse/HAWKULARQE-46 > Project: Hawkular QE > Issue Type: Task > Environment: From hrupp Status 2/23/2017 - Agent Release 0.28 > Major change to wildfly agent internals - it now restarts the agent > service when an agent config is changed. > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:30:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 11:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-63: ----------------------------------- Comment: was deleted (was: From JMazz: The only thing added post-0.28.0.Final was this Java Agent stuff. The Wildfly Agent (the thing you've been testing with) hasn't changed - it should work the same as before. The Java Agent that was introduced should work the same as that WildFly agent except: 1) it is installed via the -javaagent option when launching a JVM, not injected in standalone.xml within WildFly itself 2) it uses its own YAML configuration file rather than XML in the standalone.xml (thought the yaml setting names mimic the XML element/attribute names - e.g. metric-set-dmr, local-dmr, etc). Example yaml files are found here (see the real-config*.yaml ones): https://github.com/hawkular/hawkular-agent/tree/master/hawkular-javaagent/src/test/resources 3) You cannot run Java Agent directly in a Host Controller - but since domain mode isn't supported in this Middleware Manager stuff, I doubt you care about that. Really, other than that, this Java Agent should behave just like the WildFly Agent. That is in theory - in actuality, we'll need testing to find the places that are broken But the pieces that are going to be broke are probably not in the agent directly, but in the Middleware Manager UI that hardcoded some things it expects when the agent is deployed as a WildFly subsystem. We would need to fix those kinds of things.) > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:30:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 11:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-63: ----------------------------------- Comment: was deleted (was: On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli wrote: Just released Hawkular Java Agent 0.29.1.Final that contains a new feature. To support deploying Java Agent within containers (though this feature isn't restricted to that use-case), you can configure many settings in the Java Agent YAML config with ${x} expressions (similar to how HWFA can be configured in standalone.xml). It supports getting values from system properties, environment variables, with default values optionally defined. The following expressions are supported - hopefully this is self-explanatory: ${some.system.property} ${some.system.property:a-default-value} ${ENV~SOME_ENV_VAR} ${ENV~SOME_ENV_VAR:a-default-value} Not all properties support expressions (most don't need them) but properties that define things like hosts, ports, urls, passwords, filepaths, do support expressions. If I missed any, or if you'd like a property to support expressions that does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/projects/HWKAGENT) > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:30:01 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 11:30:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381017#comment-13381017 ] Matt Mahoney commented on HAWKULARQE-63: ---------------------------------------- There is no developer doc on Agent changes, thus rolled up emails on the subject. JMazz is the go-to developer for questions on the changes. https://mojo.redhat.com/docs/DOC-1131931 > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:47:00 2017 From: issues at jboss.org (Martin Cimbalek (JIRA)) Date: Mon, 20 Mar 2017 11:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1489) Repeated fireAllRules() causes firing rules multiple times when using OOPath + JPA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Cimbalek reassigned DROOLS-1489: --------------------------------------- Assignee: Martin Cimbalek (was: Mario Fusco) > Repeated fireAllRules() causes firing rules multiple times when using OOPath + JPA > ---------------------------------------------------------------------------------- > > Key: DROOLS-1489 > URL: https://issues.jboss.org/browse/DROOLS-1489 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta8 > Reporter: Martin Cimbalek > Assignee: Martin Cimbalek > Labels: reported-by-qe > > Repeated calling fireAllRules causes firing rules repeatedely when using OOPath in combination with JPA persistence even when facts were not modified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:47:00 2017 From: issues at jboss.org (chandra vudumula (JIRA)) Date: Mon, 20 Mar 2017 11:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Unable to see LocalDateTime specific operations for comparison In-Reply-To: References: Message-ID: chandra vudumula created DROOLS-1490: ---------------------------------------- Summary: Unable to see LocalDateTime specific operations for comparison Key: DROOLS-1490 URL: https://issues.jboss.org/browse/DROOLS-1490 Project: Drools Issue Type: Feature Request Reporter: chandra vudumula Assignee: Edson Tirelli Attachments: image-2017-03-20-11-45-20-413.png Hi, I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:47:00 2017 From: issues at jboss.org (Martin Cimbalek (JIRA)) Date: Mon, 20 Mar 2017 11:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1489) Repeated fireAllRules() causes firing rules multiple times when using OOPath + JPA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Cimbalek reassigned DROOLS-1489: --------------------------------------- Assignee: Mario Fusco (was: Martin Cimbalek) > Repeated fireAllRules() causes firing rules multiple times when using OOPath + JPA > ---------------------------------------------------------------------------------- > > Key: DROOLS-1489 > URL: https://issues.jboss.org/browse/DROOLS-1489 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta8 > Reporter: Martin Cimbalek > Assignee: Mario Fusco > Labels: reported-by-qe > > Repeated calling fireAllRules causes firing rules repeatedely when using OOPath in combination with JPA persistence even when facts were not modified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:47:00 2017 From: issues at jboss.org (chandra vudumula (JIRA)) Date: Mon, 20 Mar 2017 11:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Unable to see LocalDateTime specific operations for comparison In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chandra vudumula updated DROOLS-1490: ------------------------------------- Labels: (was: new_and_noteworthy) > Unable to see LocalDateTime specific operations for comparison > -------------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Feature Request > Reporter: chandra vudumula > Assignee: Edson Tirelli > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:48:00 2017 From: issues at jboss.org (chandra vudumula (JIRA)) Date: Mon, 20 Mar 2017 11:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Unable to see LocalDateTime specific operations for comparison In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chandra vudumula updated DROOLS-1490: ------------------------------------- Issue Type: Bug (was: Feature Request) > Unable to see LocalDateTime specific operations for comparison > -------------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Bug > Reporter: chandra vudumula > Assignee: Edson Tirelli > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:50:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 20 Mar 2017 11:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1490: ---------------------------------- Summary: Improve temporal operators to support java.time classes (was: Unable to see LocalDateTime specific operations for comparison) > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Bug > Reporter: chandra vudumula > Assignee: Edson Tirelli > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:51:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 20 Mar 2017 11:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli reassigned DROOLS-1490: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Mario Fusco > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:51:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 20 Mar 2017 11:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1490: ---------------------------------- Component/s: core engine Affects Version/s: 7.0.0.Beta7 > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Edson Tirelli > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:52:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 20 Mar 2017 11:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381036#comment-13381036 ] Edson Tirelli commented on DROOLS-1490: --------------------------------------- [~mfusco] this affects both the core engine and the workbench. This ticket is to improve the core engine and once that is done, we need to create a separate ticket for the workbench. > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Mario Fusco > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 11:55:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 20 Mar 2017 11:55:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7893) RegistryTestCase and ServiceProviderRegistrationTestCase fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-7893: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9831 (was: https://github.com/wildfly/wildfly/pull/9583) > RegistryTestCase and ServiceProviderRegistrationTestCase fail with security manager > ----------------------------------------------------------------------------------- > > Key: WFLY-7893 > URL: https://issues.jboss.org/browse/WFLY-7893 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ingo Weiss > > *org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp)#test* > {{export MYTESTIP_1=192.168.1.50}} > {{export MYTESTIP_2=192.168.1.51}} > {{sudo ifconfig em1:0 192.168.1.50}} > {{sudo ifconfig em1:1 192.168.1.51}} > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.clustering -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dtest=RegistryTestCase -Dsecurity.manager}} > fails with: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: registry.jar > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:141) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:121) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:83) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:236) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.deploy(ClientDeployer.java:93) > at org.jboss.as.test.clustering.NodeUtil.deploy(NodeUtil.java:42) > at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.beforeTestMethod(ClusterAbstractTestCase.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:463) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:108) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:241) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:77) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:53) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"registry.jar\".component.RegistryBean.START" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"registry.jar\".component.RegistryBean.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > Caused by: javax.ejb.EJBException: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"getClassLoader\")\" in code source \"(vfs:/content/registry.jar )\" of \"ModuleClassLoader for Module \"deployment.registry.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"getClassLoader\")\" in code source \"(vfs:/content/registry.jar )\" of \"ModuleClassLoader for Module \"deployment.registry.jar:main\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"registry.jar\".component.RegistryBean.START"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:135) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:121) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:83) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:236) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.deploy(ClientDeployer.java:93) > at org.jboss.as.test.clustering.NodeUtil.deploy(NodeUtil.java:42) > at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.beforeTestMethod(ClusterAbstractTestCase.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:463) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:108) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:241) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:77) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:53) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {code} > *org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp)#test* > {{export MYTESTIP_1=192.168.1.50}} > {{export MYTESTIP_2=192.168.1.51}} > {{sudo ifconfig em1:0 192.168.1.50}} > {{sudo ifconfig em1:1 192.168.1.51}} > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.clustering -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dtest=ServiceProviderRegistrationTestCase -Dsecurity.manager}} > fails with: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: service-provider-registration.jar > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:141) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:121) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:83) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:236) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.deploy(ClientDeployer.java:93) > at org.jboss.as.test.clustering.NodeUtil.deploy(NodeUtil.java:42) > at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.beforeTestMethod(ClusterAbstractTestCase.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:463) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:108) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:241) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:77) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:53) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"service-provider-registration.jar\".component.ServiceProviderRegistrationBean.START" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"service-provider-registration.jar\".component.ServiceProviderRegistrationBean.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > Caused by: javax.ejb.EJBException: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"getClassLoader\")\" in code source \"(vfs:/content/service-provider-registration.jar )\" of \"ModuleClassLoader for Module \"deployment.service-provider-registration.jar:main\" from Service Module Loader\") > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"getClassLoader\")\" in code source \"(vfs:/content/service-provider-registration.jar )\" of \"ModuleClassLoader for Module \"deployment.service-provider-registration.jar:main\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"service-provider-registration.jar\".component.ServiceProviderRegistrationBean.START"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:135) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:121) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:83) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:236) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.deploy(ClientDeployer.java:93) > at org.jboss.as.test.clustering.NodeUtil.deploy(NodeUtil.java:42) > at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.beforeTestMethod(ClusterAbstractTestCase.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:463) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:108) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:241) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:77) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:53) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 12:11:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 20 Mar 2017 12:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381054#comment-13381054 ] Brian Stansberry commented on WFCORE-2351: ------------------------------------------ Right; all that matters is REMOVED. That means the ContainerStateMonitor was still holding a ref to a ServiceController object in one of its internal collections, but MSC itself does not. We don't care about such a object as it's no longer relevant to MSC. ServiceControllers in other states are still relevant. I've incorporated that commit in my branch for WFCORE-1762. It turns out that fix is necessary to get the 1762 stuff to work correctly. So the eventual 1762 PR should cover both JIRAs. > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2351 > URL: https://issues.jboss.org/browse/WFCORE-2351 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute. > *Command with wrong filled relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource) > {code} > *You can see this log.* > Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there. > {code} > 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("credential-store" => "CredStore108") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"] > } > 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108] > {code} > *Now we try process same command without relative-to attribute* > {code} > /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > *Result is success but we can notice this in log:* > {code} > 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.server.path."non.exist.path.resource" (no longer required) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 12:47:02 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 20 Mar 2017 12:47:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-1490: ---------------------------------- Issue Type: Enhancement (was: Bug) > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Mario Fusco > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 12:48:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Mon, 20 Mar 2017 12:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381083#comment-13381083 ] Edson Tirelli commented on DROOLS-1490: --------------------------------------- [~dukechandu] I am setting the ticket type as enhancement, as this is new to java 8/Drools 7, as previously discussed by e-mail. > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Mario Fusco > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 13:00:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Mon, 20 Mar 2017 13:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-736) Fix the KBuilder API so that XLS and CSV files are different types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-736. -------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/jbpm/commit/e890d200 > Fix the KBuilder API so that XLS and CSV files are different types > ------------------------------------------------------------------ > > Key: DROOLS-736 > URL: https://issues.jboss.org/browse/DROOLS-736 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Marco Rietveld > Assignee: Mario Fusco > Fix For: 7.0.0.Final > > > For more information, see: > - https://bugzilla.redhat.com/show_bug.cgi?id=1199256 > - https://issues.jboss.org/browse/SWITCHYARD-2583 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 13:07:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Mon, 20 Mar 2017 13:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8407) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma reassigned WFLY-8407: -------------------------------- Assignee: Farah Juma (was: Darran Lofthouse) > AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-8407 > URL: https://issues.jboss.org/browse/WFLY-8407 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Tomaz Cerar > Assignee: Farah Juma > > jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration > but it is not wired to actual client configuration. > As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 13:28:00 2017 From: issues at jboss.org (chandra vudumula (JIRA)) Date: Mon, 20 Mar 2017 13:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381117#comment-13381117 ] chandra vudumula commented on DROOLS-1490: ------------------------------------------ Thank you for the update > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Mario Fusco > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 14:22:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Mon, 20 Mar 2017 14:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2561) Regression when executing CLI command directly from command line on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise moved JBEAP-9704 to WFCORE-2561: ----------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2561 (was: JBEAP-9704) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI Scripts (was: CLI) (was: Scripts) Affects Version/s: (was: 7.1.0.DR14) Affects Testing: (was: Regression) > Regression when executing CLI command directly from command line on Windows > --------------------------------------------------------------------------- > > Key: WFCORE-2561 > URL: https://issues.jboss.org/browse/WFCORE-2561 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Environment: Windows > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Blocker > > This CLI command \[1\] was working with EAP 7.1.0.DR13 and previous versions of EAP including EAP 7.0, but stopped working with jboss-cli.bat from EAP 7.1.0.DR14 with \[2\]. > As this is regression marking as blocker. Workaround for customer would mean need to update all its commands in scripts to use quotes and quotes escaping. > \[1\] > {noformat} > jboss-cli.bat --connect --controller=127.0.0.1:9990 --commands=:read-attribute(name=server-state) > {noformat} > Note we execute this command from JVM as list => > {noformat} > ["jboss-cli.bat", "--connect", "--controller=127.0.0.1:9990", "--commands=:read-attribute(name=server-state)"].execute() > {noformat}, thus by JVM it should be provided as individual parameters. > \[2\] > {noformat} > else was unexpected at this time. > {noformat} > Most likely the regression is caused by fix for [JBEAP-8808] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 15:26:00 2017 From: issues at jboss.org (Dennis Reed (JIRA)) Date: Mon, 20 Mar 2017 15:26:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2562) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: Dennis Reed created WFCORE-2562: ----------------------------------- Summary: NullPointerException when removing configuration history Key: WFCORE-2562 URL: https://issues.jboss.org/browse/WFCORE-2562 Project: WildFly Core Issue Type: Support Patch Components: Domain Management Affects Versions: 2.1.0.Final Reporter: Dennis Reed Assignee: Brian Stansberry org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException, aborting startup of EAP. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 15:28:00 2017 From: issues at jboss.org (Dennis Reed (JIRA)) Date: Mon, 20 Mar 2017 15:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2562) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Reed updated WFCORE-2562: -------------------------------- Description: org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. This method is used while removing old history directories during boot, and the NullPointerException causes the EAP boot to abort. was: org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException, aborting startup of EAP. > NullPointerException when removing configuration history > -------------------------------------------------------- > > Key: WFCORE-2562 > URL: https://issues.jboss.org/browse/WFCORE-2562 > Project: WildFly Core > Issue Type: Support Patch > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Brian Stansberry > > org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. > If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. > This method is used while removing old history directories during boot, and the NullPointerException causes the EAP boot to abort. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 15:30:00 2017 From: issues at jboss.org (Dennis Reed (JIRA)) Date: Mon, 20 Mar 2017 15:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2562) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Reed updated WFCORE-2562: -------------------------------- Description: org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. This method is used while removing old configuration history directories during boot, and the NullPointerException causes the EAP boot to abort. was: org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. This method is used while removing old history directories during boot, and the NullPointerException causes the EAP boot to abort. > NullPointerException when removing configuration history > -------------------------------------------------------- > > Key: WFCORE-2562 > URL: https://issues.jboss.org/browse/WFCORE-2562 > Project: WildFly Core > Issue Type: Support Patch > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Brian Stansberry > > org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. > If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. > This method is used while removing old configuration history directories during boot, and the NullPointerException causes the EAP boot to abort. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 15:42:00 2017 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Mon, 20 Mar 2017 15:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8409) Backward compatibility: IIOP doesn't work with standalone-full profile from EAP 7.0.0 In-Reply-To: References: Message-ID: Tomasz Adamski created WFLY-8409: ------------------------------------ Summary: Backward compatibility: IIOP doesn't work with standalone-full profile from EAP 7.0.0 Key: WFLY-8409 URL: https://issues.jboss.org/browse/WFLY-8409 Project: WildFly Issue Type: Bug Components: IIOP Affects Versions: 10.1.0.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski Priority: Blocker Fix For: 11.0.0.Beta1 *Description of problem:* IIOP doesn't work with standalone-full profile from EAP 7.0.0. This is regression against EAP 7.1.0.DR10. This backward compatibility works correctly in EAP 6.x. EAP 6.4.0 works correctly with standalone-full.xml from EAP 6.0.0. {code:diff} @@ -270,8 +271,9 @@ - + + @@ -304,7 +306,7 @@ {code} *How reproducible:* Always *Steps to Reproduce:* # get fresh EAP 7.1.0.DR11 # rm standalone/configuration/standalone-full.xml # cp $\{EAP_7_0_0\}/standalone/configuration/standalone-full.xml standalone/configuration/ # ./bin/standalone.sh -c standalone-full.xml *Actual results:* {noformat} ... 10:43:53,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 42) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: "WFLYIIOP0111: SSL has not been configured but ssl-port property has been specified" 10:43:53,515 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 42) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: "WFLYIIOP0111: SSL has not been configured but ssl-port property has been specified" ... 10:43:55,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 3272ms - Started 385 of 615 services (419 services are lazy, passive or on-demand) {noformat} *Expected results:* No error on output. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 16:05:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Mon, 20 Mar 2017 16:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381017#comment-13381017 ] Matt Mahoney edited comment on HAWKULARQE-63 at 3/20/17 4:04 PM: ----------------------------------------------------------------- There is no developer doc on Agent changes, thus rolled up emails on the subject. JMazz is the go-to developer for questions on the changes. https://mojo.redhat.com/docs/DOC-1131931 Also Ref: https://github.com/hawkular/hawkular-agent was (Author: mmahoney): There is no developer doc on Agent changes, thus rolled up emails on the subject. JMazz is the go-to developer for questions on the changes. https://mojo.redhat.com/docs/DOC-1131931 > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 21:37:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Mon, 20 Mar 2017 21:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2402: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Required attributes of elytron key-store creation add operation > --------------------------------------------------------------- > > Key: WFCORE-2402 > URL: https://issues.jboss.org/browse/WFCORE-2402 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Minimal CLI command to create key store is > {code} > /subsystem=elytron/key-store=server:add(type="JKS") > {code} > But it has these problems: > * Password attribute has to be required. I can't think of case when that could be ommited. > * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 21:39:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Mon, 20 Mar 2017 21:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2402: ------------------------------------- Assignee: Darran Lofthouse (was: Ilia Vassilev) > Required attributes of elytron key-store creation add operation > --------------------------------------------------------------- > > Key: WFCORE-2402 > URL: https://issues.jboss.org/browse/WFCORE-2402 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Minimal CLI command to create key store is > {code} > /subsystem=elytron/key-store=server:add(type="JKS") > {code} > But it has these problems: > * Password attribute has to be required. I can't think of case when that could be ommited. > * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 21:39:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Mon, 20 Mar 2017 21:39:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2402: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Required attributes of elytron key-store creation add operation > --------------------------------------------------------------- > > Key: WFCORE-2402 > URL: https://issues.jboss.org/browse/WFCORE-2402 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Minimal CLI command to create key store is > {code} > /subsystem=elytron/key-store=server:add(type="JKS") > {code} > But it has these problems: > * Password attribute has to be required. I can't think of case when that could be ommited. > * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 21:39:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Mon, 20 Mar 2017 21:39:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2402: ------------------------------------- Assignee: Darran Lofthouse (was: Ilia Vassilev) > Required attributes of elytron key-store creation add operation > --------------------------------------------------------------- > > Key: WFCORE-2402 > URL: https://issues.jboss.org/browse/WFCORE-2402 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Minimal CLI command to create key store is > {code} > /subsystem=elytron/key-store=server:add(type="JKS") > {code} > But it has these problems: > * Password attribute has to be required. I can't think of case when that could be ommited. > * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 21:43:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 20 Mar 2017 21:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8411) Test suite depends on the JBEAP-5863 bug In-Reply-To: References: Message-ID: Brian Stansberry created WFLY-8411: -------------------------------------- Summary: Test suite depends on the JBEAP-5863 bug Key: WFLY-8411 URL: https://issues.jboss.org/browse/WFLY-8411 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry A number of places in the full WildFly test suite depend on the incorrect behavior that WFCORE-1762 is meant to fix. Tests execute operations that should fail and assume they will succeed. InterDeploymentDependenciesTestCase and InterDeploymentDependenciesEarTestCase are like this. There may be (many) others. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 21:43:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 20 Mar 2017 21:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8410) Test suite depends on the WFCORE-1762 bug In-Reply-To: References: Message-ID: Brian Stansberry created WFLY-8410: -------------------------------------- Summary: Test suite depends on the WFCORE-1762 bug Key: WFLY-8410 URL: https://issues.jboss.org/browse/WFLY-8410 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry A number of places in the full WildFly test suite depend on the incorrect behavior that WFCORE-1762 is meant to fix. Tests execute operations that should fail and assume they will succeed. InterDeploymentDependenciesTestCase and InterDeploymentDependenciesEarTestCase are like this. There may be (many) others. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 01:20:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 21 Mar 2017 01:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) Perform and document a small load test run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen resolved HAWKULARQE-47. ----------------------------------- Resolution: Done > Perform and document a small load test run > ------------------------------------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 01:21:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 21 Mar 2017 01:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381234#comment-13381234 ] viet nguyen commented on HAWKULARQE-73: --------------------------------------- master/node1: https://b16.jonqe.lab.eng.bos.redhat.com:8443/console node2: b20.jonqe.lab.eng.bos.redhat.com:8443/console > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - how many pods > - verify metrics definition count > - verify metrics data -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 01:22:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 21 Mar 2017 01:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen resolved HAWKULARQE-73. ----------------------------------- Resolution: Done > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - how many pods > - verify metrics definition count > - verify metrics data -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 01:23:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 21 Mar 2017 01:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-74: ------------------------------------- Summary: 2nd baselines Key: HAWKULARQE-74 URL: https://issues.jboss.org/browse/HAWKULARQE-74 Project: Hawkular QE Issue Type: Sub-task Reporter: viet nguyen Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 01:23:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Tue, 21 Mar 2017 01:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-74: ------------------------------------- Assignee: viet nguyen (was: Michael Foley) > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 02:06:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Tue, 21 Mar 2017 02:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2399) Removing and re-adding alias to credential store leads to Duplicate resource failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2399: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Removing and re-adding alias to credential store leads to Duplicate resource failure > ------------------------------------------------------------------------------------ > > Key: WFCORE-2399 > URL: https://issues.jboss.org/browse/WFCORE-2399 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store > > When an alias is removed from a credential store and added once more, the {{add}} operation fails with Duplicate resource message. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8144 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 02:33:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Tue, 21 Mar 2017 02:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2163) Potential NPE in TP.handleProbe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381244#comment-13381244 ] Bela Ban commented on JGRP-2163: -------------------------------- OK, thanks, removed the redundant null checks > Potential NPE in TP.handleProbe > ------------------------------- > > Key: JGRP-2163 > URL: https://issues.jboss.org/browse/JGRP-2163 > Project: JGroups > Issue Type: Bug > Reporter: Zoltan Farkas > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.14 > > > at: > https://github.com/belaban/JGroups/blob/3.6/src/org/jgroups/protocols/TP.java#L1398 > {code} > public Map handleProbe(String... keys) { > Map retval=new HashMap<>(keys != null? keys.length : 2); > for(String key: keys) { > {code} > keys is checked for null and on the next line it is de-refferenced... > this code fill fail with NPE if keys is null... > This issue is discovered by findbugs NP_NULL_ON_SOME_PATH check. Highly recommend running findbugs + coverity (free for OS projects). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 03:07:02 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 21 Mar 2017 03:07:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1016) Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek moved WFCORE-2555 to ELY-1016: ------------------------------------------- Project: WildFly Elytron (was: WildFly Core) Key: ELY-1016 (was: WFCORE-2555) Component/s: Credential Store (was: Security) > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > ----------------------------------------------------------------------------- > > Key: ELY-1016 > URL: https://issues.jboss.org/browse/ELY-1016 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek ?v?bek > Assignee: Hynek ?v?bek > > Cache in KeyStoreCredentialStore must work with lowercase aliases (keys) too. > When I work directly with CredentialStore API I see there problem with case sensitive aliases. I located problem to used cache. > There is one place when we store new entry and where is not key in lowercase. > e.g. > https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/credential/store/impl/KeyStoreCredentialStore.java#L326 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 03:24:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 21 Mar 2017 03:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2563) Missing failure description for incorrect module in Elytron dir-context In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2563: ------------------------------------ Summary: Missing failure description for incorrect module in Elytron dir-context Key: WFCORE-2563 URL: https://issues.jboss.org/browse/WFCORE-2563 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse In case when {{module}} attribute from Elytron {{dir-context}} includes module which does not exist, then insufficient failure description is provided - it only prints name of given module. It should rather inform that given module does not exist. See: {code} /subsystem=elytron/dir-context=someDirContext:add(url=localhost,module=wrong.module) { "outcome" => "failed", "failure-description" => "wrong.module", "rolled-back" => true } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 03:25:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 21 Mar 2017 03:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2563) Missing failure description for incorrect module in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2563: --------------------------------- Affects Version/s: 3.0.0.Beta9 > Missing failure description for incorrect module in Elytron dir-context > ----------------------------------------------------------------------- > > Key: WFCORE-2563 > URL: https://issues.jboss.org/browse/WFCORE-2563 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when {{module}} attribute from Elytron {{dir-context}} includes module which does not exist, then insufficient failure description is provided - it only prints name of given module. It should rather inform that given module does not exist. > See: > {code} > /subsystem=elytron/dir-context=someDirContext:add(url=localhost,module=wrong.module) > { > "outcome" => "failed", > "failure-description" => "wrong.module", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 03:25:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 21 Mar 2017 03:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2563) Missing failure description for incorrect module in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2563: --------------------------------- Labels: user_experience (was: ) > Missing failure description for incorrect module in Elytron dir-context > ----------------------------------------------------------------------- > > Key: WFCORE-2563 > URL: https://issues.jboss.org/browse/WFCORE-2563 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when {{module}} attribute from Elytron {{dir-context}} includes module which does not exist, then insufficient failure description is provided - it only prints name of given module. It should rather inform that given module does not exist. > See: > {code} > /subsystem=elytron/dir-context=someDirContext:add(url=localhost,module=wrong.module) > { > "outcome" => "failed", > "failure-description" => "wrong.module", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 04:18:00 2017 From: issues at jboss.org (Michal Jurc (JIRA)) Date: Tue, 21 Mar 2017 04:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8412) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties In-Reply-To: References: Message-ID: Michal Jurc created WFLY-8412: --------------------------------- Summary: AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties Key: WFLY-8412 URL: https://issues.jboss.org/browse/WFLY-8412 Project: WildFly Issue Type: Bug Components: EJB Reporter: Michal Jurc Assignee: Farah Juma jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration but it is not wired to actual client configuration. As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 04:21:01 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Tue, 21 Mar 2017 04:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8413) Clients using SecurityClientFactory are not authenticated when using Elytron In-Reply-To: References: Message-ID: Josef Cacek created WFLY-8413: --------------------------------- Summary: Clients using SecurityClientFactory are not authenticated when using Elytron Key: WFLY-8413 URL: https://issues.jboss.org/browse/WFLY-8413 Project: WildFly Issue Type: Bug Components: EJB, Security Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker Clients using {{org.jboss.security.client.SecurityClientFactory}} are not authenticated when Elytron security is used on the server. For instance if a servlet authenticates to call a protected EJB: {code:java} SecurityClient client = SecurityClientFactory.getSecurityClient(); client.setSimple("user", "password"); client.login(); ejb.callProtectedMethod(); // ... {code} Clients with such code don't work with Elytron, which makes easy application migration to Elytron impossible. Setting priority to blocker as we need to provide a simple migration way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 05:15:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 21 Mar 2017 05:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: Jeff Mesnil created WFCORE-2564: ----------------------------------- Summary: Customize resolve-path handle to handle absolute paths Key: WFCORE-2564 URL: https://issues.jboss.org/browse/WFCORE-2564 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Beta9 Reporter: Jeff Mesnil Assignee: Brian Stansberry The :resolve-path operation will always resolve the path based on the relative-to attribute. In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 07:06:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Tue, 21 Mar 2017 07:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-70) Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381461#comment-13381461 ] Sunil kondkar commented on HAWKULARQE-70: ----------------------------------------- -CF-UI Docker Scripts are modified to stop, remove and then create a new CFME container. -Configured the Jenkins job with Shell scripts to git clone and then execute docker scripts on test environment to stop, remove and then create a new CFME container. -Jenkins job: http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/miq-ms-cfui-nightly-test/ -The Jenkins slave node is now configured to be able to show vnc using: vncviewer 10.8.184.19:5906 -The Jenkins job is pass on the branch where scripts are committed: Branch: https://github.com/Hawkular-QE/cf-ui/tree/dockerscripts Test runs: http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/miq-ms-cfui-nightly-test/33 http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/miq-ms-cfui-nightly-test/34 PR: https://github.com/Hawkular-QE/cf-ui/pull/149 > Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server > --------------------------------------------------------------------------------- > > Key: HAWKULARQE-70 > URL: https://issues.jboss.org/browse/HAWKULARQE-70 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Need of the task: > To make sure the CFME docker instance that we use on Jenkins nightly run has CFME containers always running, we use docker scripts. > These are existing shell scripts which are using old methods to create cfme docker container and then start the cfme instance which are irrelevant now: > These are located at: > https://github.com/Hawkular-QE/cf-ui/tree/master/scripts/automation/docker > This task is to: > 1) Modify the scripts (common.sh, start.sh) to: > -Stop the CFME instance > -Start the CFME instance > -Check if the URL is ready using curl > -Check the logs if CFME is started > 2) Git clone the modified scripts to CFME server > 3) Execute the scripts on CFME server > ( Use 'execute shell script' on Jenkins nightly job to ssh/git clone and execute script on CFME server) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 07:15:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 21 Mar 2017 07:15:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2565) Incorrect permission class-name should throw exception at runtime In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2565: ------------------------------------ Summary: Incorrect permission class-name should throw exception at runtime Key: WFCORE-2565 URL: https://issues.jboss.org/browse/WFCORE-2565 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse In case when some permission mapper (tried with constant-permission-mapper and simple-permission-mapper) includes permission with non-existent class-name then it seems that no exception is thrown during runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 07:15:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 21 Mar 2017 07:15:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2565) Incorrect permission class-name should throw exception at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2565: --------------------------------- Steps to Reproduce: Add non-existent permission into default-permission-mapper: {code} /subsystem=elytron/constant-permission-mapper=default-permission-mapper:write-attribute(name=permissions[4],value={class-name=WrongName}) {code} and use this mapper at runtime. No exception is thrown. was: Add non-existent permission into default {default-permission-mapper}: {code} /subsystem=elytron/constant-permission-mapper=default-permission-mapper:write-attribute(name=permissions[4],value={class-name=WrongName}) {code} and use this mapper at runtime. No exception is thrown. > Incorrect permission class-name should throw exception at runtime > ----------------------------------------------------------------- > > Key: WFCORE-2565 > URL: https://issues.jboss.org/browse/WFCORE-2565 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when some permission mapper (tried with constant-permission-mapper and simple-permission-mapper) includes permission with non-existent class-name then it seems that no exception is thrown during runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 07:16:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 21 Mar 2017 07:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2565) Incorrect permission class-name should throw exception at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2565: --------------------------------- Affects Version/s: 3.0.0.Beta9 > Incorrect permission class-name should throw exception at runtime > ----------------------------------------------------------------- > > Key: WFCORE-2565 > URL: https://issues.jboss.org/browse/WFCORE-2565 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when some permission mapper (tried with constant-permission-mapper and simple-permission-mapper) includes permission with non-existent class-name then it seems that no exception is thrown during runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:00:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 08:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-647: --------------------------------- Fix Version/s: 1.0.4.CR1 1.1.0.Beta10 > MechanismDatabase create SSL_ aliases incompletely > -------------------------------------------------- > > Key: ELY-647 > URL: https://issues.jboss.org/browse/ELY-647 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta10, 1.0.4.CR1 > > > SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases. > MechanismDatabase.properties contains for example: > {code:java} > TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA > {code} > The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:00:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 08:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1017) Release WildFly Elytron 1.0.0.Beta4 In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1017: ------------------------------------- Summary: Release WildFly Elytron 1.0.0.Beta4 Key: ELY-1017 URL: https://issues.jboss.org/browse/ELY-1017 Project: WildFly Elytron Issue Type: Release Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.4.CR1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:01:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 08:01:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1017) Release WildFly Elytron 1.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1017: ---------------------------------- Summary: Release WildFly Elytron 1.0.4.Final (was: Release WildFly Elytron 1.0.0.Beta4) > Release WildFly Elytron 1.0.4.Final > ----------------------------------- > > Key: ELY-1017 > URL: https://issues.jboss.org/browse/ELY-1017 > Project: WildFly Elytron > Issue Type: Release > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.4.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:10:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 08:10:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1017) Release WildFly Elytron 1.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-1017. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.0.4.Final > ----------------------------------- > > Key: ELY-1017 > URL: https://issues.jboss.org/browse/ELY-1017 > Project: WildFly Elytron > Issue Type: Release > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.4.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:25:02 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 08:25:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: Jan Kalina created WFCORE-2566: ---------------------------------- Summary: Subsystem parsing tests ignores wrong END_ELEMENT Key: WFCORE-2566 URL: https://issues.jboss.org/browse/WFCORE-2566 Project: WildFly Core Issue Type: Bug Reporter: Jan Kalina Assignee: Jan Kalina Priority: Minor Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:28:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 08:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2566: ------------------------------- Steps to Reproduce: * add some *requireNoContent* in the end of subsystem element parsing, where it should not be * if there are only END_ELEMENTs after, test will be successful * test will fail only if I add some (correct) START_ELEMENT after affected place (test should check this to fail without following elements too) > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:30:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 08:30:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reopened WFCORE-2518: -------------------------------- Reopening - bug of parsing > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:35:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 08:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2566: ------------------------------- Description: Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/88 unnoticed. was: Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/88 unnoticed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:38:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 08:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned WFCORE-2518: ---------------------------------------- Assignee: Darran Lofthouse (was: Jan Kalina) > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:41:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-2518. -------------------------------------- Resolution: Done > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 08:57:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 08:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-923) Elytron LDAP caching realm should cache attributes and credentials In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reopened ELY-923: ---------------------------- Reopening: requested caching evidences too > Elytron LDAP caching realm should cache attributes and credentials > ------------------------------------------------------------------ > > Key: ELY-923 > URL: https://issues.jboss.org/browse/ELY-923 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta21 > Reporter: Ondrej Kotek > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta28 > > > Elytron {{caching-realm}} backed by {{ldap-realm}} provides caching for identity objects but not for related credentials and attributes. This is currently due to design of {{ldap-realm}} (like in case of {{filesystem-realm}}, see ELY-915). > Credentials and attributes should not be loaded from LDAP for a cache hit. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 09:02:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 09:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2566: ------------------------------- Component/s: Test Suite > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/88 unnoticed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 09:03:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 09:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2566: ------------------------------- Description: Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. was: Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/88 unnoticed. > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 09:04:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 09:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2566: ------------------------------- Affects Version/s: 3.0.0.Beta9 > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta9 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 09:47:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 21 Mar 2017 09:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2562) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-2562: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1434141 Bugzilla Update: Perform > NullPointerException when removing configuration history > -------------------------------------------------------- > > Key: WFCORE-2562 > URL: https://issues.jboss.org/browse/WFCORE-2562 > Project: WildFly Core > Issue Type: Support Patch > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Brian Stansberry > > org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. > If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. > This method is used while removing old configuration history directories during boot, and the NullPointerException causes the EAP boot to abort. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 09:58:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Tue, 21 Mar 2017 09:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7738) XTS suspend tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381659#comment-13381659 ] Ivo Studensky commented on WFLY-7738: ------------------------------------- Actual fix for this issue will be similar to WFLY-6192 once it is reviewed. > XTS suspend tests fail with security manager > -------------------------------------------- > > Key: WFLY-7738 > URL: https://issues.jboss.org/browse/WFLY-7738 > Project: WildFly > Issue Type: Bug > Components: Test Suite, Web Services, XTS > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=AtomicTransactionSuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-5) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsat.AtomicTransactionExecutionService.init(AtomicTransactionExecutionService.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} > *org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BusinessActivitySuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-3) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsba.BusinessActivityExecutionService.init(BusinessActivityExecutionService.java:76) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 10:23:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Tue, 21 Mar 2017 10:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1018) Ensure that legacy configuration gets processed when no Elytron client configuration is found In-Reply-To: References: Message-ID: Farah Juma created ELY-1018: ------------------------------- Summary: Ensure that legacy configuration gets processed when no Elytron client configuration is found Key: ELY-1018 URL: https://issues.jboss.org/browse/ELY-1018 Project: WildFly Elytron Issue Type: Bug Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 10:27:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 21 Mar 2017 10:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7087) Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-7087: --------------------------------- Fix Version/s: 12.0.0.Alpha1 > Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade > ----------------------------------------------------------------------- > > Key: WFLY-7087 > URL: https://issues.jboss.org/browse/WFLY-7087 > Project: WildFly > Issue Type: Task > Components: Clustering > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > http://belaban.blogspot.cz/2016/09/removing-thread-pools-in-jgroups-40.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 10:29:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 21 Mar 2017 10:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7087) Deprecate internal, timer and oob thread pools in last release before JGroups 4.x upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-7087: --------------------------------- Summary: Deprecate internal, timer and oob thread pools in last release before JGroups 4.x upgrade (was: Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade) > Deprecate internal, timer and oob thread pools in last release before JGroups 4.x upgrade > ----------------------------------------------------------------------------------------- > > Key: WFLY-7087 > URL: https://issues.jboss.org/browse/WFLY-7087 > Project: WildFly > Issue Type: Task > Components: Clustering > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > http://belaban.blogspot.cz/2016/09/removing-thread-pools-in-jgroups-40.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 10:32:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 21 Mar 2017 10:32:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7087) Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-7087: --------------------------------- Summary: Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade (was: Deprecate internal, timer and oob thread pools in last release before JGroups 4.x upgrade) > Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade > ----------------------------------------------------------------------- > > Key: WFLY-7087 > URL: https://issues.jboss.org/browse/WFLY-7087 > Project: WildFly > Issue Type: Task > Components: Clustering > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > http://belaban.blogspot.cz/2016/09/removing-thread-pools-in-jgroups-40.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 10:35:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 21 Mar 2017 10:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381686#comment-13381686 ] Tomaz Cerar commented on WFCORE-2566: ------------------------------------- Problems like one described cannot be tested automatically. They can be tested by having different sets of xml configurations to be tested. best thing would be to move parser to PersistentResourceXMLDescription instead of hand written one. > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta9 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:12:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Tue, 21 Mar 2017 11:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1019) Elytron, ensure BSDUnixDESCryptPasswordImpl don't suffer on sign-extension bug In-Reply-To: References: Message-ID: Martin Choma created ELY-1019: --------------------------------- Summary: Elytron, ensure BSDUnixDESCryptPasswordImpl don't suffer on sign-extension bug Key: ELY-1019 URL: https://issues.jboss.org/browse/ELY-1019 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse {code} shifts += keyShifts[i]; {code} should be also ensured by {code} shifts += keyShifts[i] & 0xff; {code} True is array keyShifts does not contain any negative value, but it doesn't neither {{IP}} or {{keyPerm}}, which are ensured ? This follow up https://issues.jboss.org/browse/JBEAP-8505 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:12:01 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Tue, 21 Mar 2017 11:12:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1019) Elytron, ensure BSDUnixDESCryptPasswordImpl don't suffer on sign-extension bug In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated ELY-1019: ------------------------------ Description: {code} shifts += keyShifts[i]; {code} should be also ensured by {code} shifts += keyShifts[i] & 0xff; {code} True is array keyShifts does not contain any negative value, but it doesn't neither {{IP}} or {{keyPerm}}, which are ensured ? This follow up https://issues.jboss.org/browse/ELY-960 was: {code} shifts += keyShifts[i]; {code} should be also ensured by {code} shifts += keyShifts[i] & 0xff; {code} True is array keyShifts does not contain any negative value, but it doesn't neither {{IP}} or {{keyPerm}}, which are ensured ? This follow up https://issues.jboss.org/browse/JBEAP-8505 > Elytron, ensure BSDUnixDESCryptPasswordImpl don't suffer on sign-extension bug > ------------------------------------------------------------------------------ > > Key: ELY-1019 > URL: https://issues.jboss.org/browse/ELY-1019 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Darran Lofthouse > > {code} > shifts += keyShifts[i]; > {code} > should be also ensured by > {code} > shifts += keyShifts[i] & 0xff; > {code} > True is array keyShifts does not contain any negative value, but it doesn't neither {{IP}} or {{keyPerm}}, which are ensured ? > This follow up https://issues.jboss.org/browse/ELY-960 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:12:02 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Tue, 21 Mar 2017 11:12:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1019) Elytron, ensure BSDUnixDESCryptPasswordImpl don't suffer on sign-extension bug In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma reassigned ELY-1019: --------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Elytron, ensure BSDUnixDESCryptPasswordImpl don't suffer on sign-extension bug > ------------------------------------------------------------------------------ > > Key: ELY-1019 > URL: https://issues.jboss.org/browse/ELY-1019 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Ilia Vassilev > > {code} > shifts += keyShifts[i]; > {code} > should be also ensured by > {code} > shifts += keyShifts[i] & 0xff; > {code} > True is array keyShifts does not contain any negative value, but it doesn't neither {{IP}} or {{keyPerm}}, which are ensured ? > This follow up https://issues.jboss.org/browse/ELY-960 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:14:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381744#comment-13381744 ] Brian Stansberry commented on WFCORE-2564: ------------------------------------------ Thoughts on how this should be done: 1) PathManager should expose a new resolveRelativePathEntry(String path, boolean possiblyAbsolute, String relativeTo) method, wherein if the possiblyAbsolute param is true, an absolute path check is performed on 'path' and if it's absolute relativeTo is ignored. AbstractPathService.isAbsoluteUnixOrWindowsPath(String path) is the check. This would let the kernel handle this kind of thing instead of extensions coding it themselves the way the AS7-5600 fix had to be done. 2) ResolvePathHandler.Builder should add a setter to let callers set a possiblyAbsolute value, which then gets passed into ResolvePathHandler, which uses it to call PathManager. 3) Default is 'false' consistent with current behavior. > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:16:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2564: ------------------------------------- Fix Version/s: 3.0.0.Beta11 I've unassigned this so it's free for anyone to pick up, but I stuck a 3.0.0 Fix Version on it because it seems like something we could get done fairly easily. The Fix Version is just to help attract attention to it if people have time; it's not a commitment. > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta11 > > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:17:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:17:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2564: ---------------------------------------- Assignee: (was: Brian Stansberry) > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Fix For: 3.0.0.Beta11 > > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:19:02 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:19:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381754#comment-13381754 ] Brian Stansberry commented on WFCORE-2564: ------------------------------------------ Whoever picks this up please ping [~jmesnil] about picking up JBEAP-9717 at the same time since that's the actual immediate use case for the change to core. Actually using the core change is a good way to make sure it's right. ;) > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Fix For: 3.0.0.Beta11 > > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:23:02 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Tue, 21 Mar 2017 11:23:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8414) EJBContext.getCallerPrincipal behaves differently in Elytron and legacy security In-Reply-To: References: Message-ID: Josef Cacek created WFLY-8414: --------------------------------- Summary: EJBContext.getCallerPrincipal behaves differently in Elytron and legacy security Key: WFLY-8414 URL: https://issues.jboss.org/browse/WFLY-8414 Project: WildFly Issue Type: Bug Components: EJB, Security Reporter: Josef Cacek Assignee: Darran Lofthouse The {{EJBContext.getCallerPrincipal()}} used in unsecured EJB method returns "anonymous" (i.e. unauthenticatedIdentity) in legacy security and it returns authenticated user-name when the default security domain ("other") is mapped to Elytron. This could complicate users migration from legacy security to Elytron. I'm not sure if this behavior was intended or if it's just a problem of how the Elytron default domain mapping works in ejb3 subsystem. If the current {{getCallerPrincipal}} behavior is correct, then we should either reuse this JIRA for Documentation changes (especially Migration guide) or close this and create a new Documentation one. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:27:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:27:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2564: ------------------------------------- Comment: was deleted (was: I've unassigned this so it's free for anyone to pick up, but I stuck a 3.0.0 Fix Version on it because it seems like something we could get done fairly easily. The Fix Version is just to help attract attention to it if people have time; it's not a commitment.) > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 3.0.0.Beta11 > > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:27:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:27:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2564: ------------------------------------- Comment: was deleted (was: Whoever picks this up please ping [~jmesnil] about picking up JBEAP-9717 at the same time since that's the actual immediate use case for the change to core. Actually using the core change is a good way to make sure it's right. ;)) > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 3.0.0.Beta11 > > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:27:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 21 Mar 2017 11:27:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2564: ---------------------------------------- Assignee: Jeff Mesnil The bit I mentioned about changing PathManager doesn't have to be part of this; the immediate issue can be resolved solely within ResolvePathHandler and its Builder. > Customize resolve-path handle to handle absolute paths > ------------------------------------------------------ > > Key: WFCORE-2564 > URL: https://issues.jboss.org/browse/WFCORE-2564 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 3.0.0.Beta11 > > > The :resolve-path operation will always resolve the path based on the relative-to attribute. > In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path. > To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:28:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 21 Mar 2017 11:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9 modular params propagation to forked processes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-1859: ----------------------------------- Assignee: Richard Opalka (was: Tomaz Cerar) > Investigate and fix JDK9 modular params propagation to forked processes > ----------------------------------------------------------------------- > > Key: WFCORE-1859 > URL: https://issues.jboss.org/browse/WFCORE-1859 > Project: WildFly Core > Issue Type: Sub-task > Components: Server, Test Suite > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 11:31:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 21 Mar 2017 11:31:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1367) Test framework for CLI-based tests can be very slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFCORE-1367. ------------------------------- Fix Version/s: 3.0.0.Beta9 Resolution: Done Looking at code, there are no timeouts involved anymore. And it looks like tests run quite fast. > Test framework for CLI-based tests can be very slow > --------------------------------------------------- > > Key: WFCORE-1367 > URL: https://issues.jboss.org/browse/WFCORE-1367 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Test Suite > Reporter: David Bosschaert > Priority: Minor > Fix For: 3.0.0.Beta9 > > > The org.jboss.as.test.integration.management.base.AbstractCliTestBase provides a suitable API for testing CLI-based operations. However, running tests with a relatively large number of CLI operations can take a *long* time, seemingly much longer than necessary. This is probably related to the fact that CLIWrapper.readAllAsOpResult() method always seems to wait until the lineTimeout has expired. > Typically the WAIT_LINETIMEOUT value is used for this argument. Shortening the timeout is not an option as I have seen cases where a test would fail when run on a slow machine, but this only happens occasionally. > It would be *much* better if a timeout was not needed for this and the test would wait until a certain operation was finished. > This can be observed in org.jboss.as.test.integration.management.cli.JmsTestCase and I also experienced it when writing the org.jboss.as.test.integration.osgi.management.OSGiManagementTestCase. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 12:23:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 21 Mar 2017 12:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5536) Recovery manager is not able to recover MDB and shows warnings on each run. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381835#comment-13381835 ] Jeff Mesnil commented on WFLY-5536: ----------------------------------- [~mwessendorf] I don't think it's been backported to EAP 6.4 with HornetQ. Artemis uses ServiceLoader to load resources related to recovery. I don't think that HornetQ had a similar feature though... > Recovery manager is not able to recover MDB and shows warnings on each run. > --------------------------------------------------------------------------- > > Key: WFLY-5536 > URL: https://issues.jboss.org/browse/WFLY-5536 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR2 > Reporter: Hayk Hovsepyan > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 10.0.0.CR5 > > Attachments: MDB_JMS_XA.log, TEST-org.jboss.as.test.jbossts.crashrec.test.JMSMdbCrashRecoveryTestCase-jta.xml > > > Recovery manager is not able to recover MDB and shows warnings. > This causes to see the same warning log in server each time recovery is run. > This happens when server is crashed before transaction state is saved. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 12:34:04 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Tue, 21 Mar 2017 12:34:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6743) Intermittent failures in PassivationTestCase.testPassivationMaxSize In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar reassigned WFLY-6743: ------------------------------------ Assignee: Radoslav Husar (was: Tomasz Adamski) > Intermittent failures in PassivationTestCase.testPassivationMaxSize > ------------------------------------------------------------------- > > Key: WFLY-6743 > URL: https://issues.jboss.org/browse/WFLY-6743 > Project: WildFly > Issue Type: Task > Components: EJB > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > 433 runs / 17 failures / 0 ignored Success rate: 96.1% > https://ci.wildfly.org/viewLog.html?buildId=19025&tab=buildResultsDiv&buildTypeId=WF_PullRequest_Windows > https://gist.github.com/rhusar/58c3c0740b4d767d53a4dd77e41679b5 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 12:57:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 12:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1018) Ensure that legacy configuration gets processed when no Elytron client configuration is found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1018: ---------------------------------- Fix Version/s: 1.1.0.Beta33 1.1.0.Beta31-SP1 > Ensure that legacy configuration gets processed when no Elytron client configuration is found > --------------------------------------------------------------------------------------------- > > Key: ELY-1018 > URL: https://issues.jboss.org/browse/ELY-1018 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 1.1.0.Beta33, 1.1.0.Beta31-SP1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:00:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Tue, 21 Mar 2017 13:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2455) Empty secret-value is not allowed in credential stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2455: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Empty secret-value is not allowed in credential stores > ------------------------------------------------------- > > Key: WFCORE-2455 > URL: https://issues.jboss.org/browse/WFCORE-2455 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store > > It's not possible to add an entry with empty secret-value into a credential store. > Masking the fact the password is empty is a valid scenario. > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0155: 'secret-value' may not be null", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add(secret-value="") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter secret-value. Values must have a minimum length of 1 characters", > "rolled-back" => true > } > {code} > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8143 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:03:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Tue, 21 Mar 2017 13:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-421) IBM JDK uses a slightly different stack for property permission checking In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated ELY-421: --------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/367 > IBM JDK uses a slightly different stack for property permission checking > ------------------------------------------------------------------------ > > Key: ELY-421 > URL: https://issues.jboss.org/browse/ELY-421 > Project: WildFly Elytron > Issue Type: Bug > Components: Security Manager > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta4, 1.0.3.Final > > > On some IBM JDKs, System.getProperty delegates to other System methods. The security manager does not account for that. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:10:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 13:10:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1020) Release WildFly Elytron 1.1.0.Beta31-SP1 In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1020: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta31-SP1 Key: ELY-1020 URL: https://issues.jboss.org/browse/ELY-1020 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta31-SP1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:21:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 13:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1020) Release WildFly Elytron 1.1.0.Beta31-SP1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-1020. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta31-SP1 > ---------------------------------------- > > Key: ELY-1020 > URL: https://issues.jboss.org/browse/ELY-1020 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta31-SP1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:23:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 13:23:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2567) Upgrade WildFly Elytron to 1.1.0.Beta31-SP1 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2567: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta31-SP1 Key: WFCORE-2567 URL: https://issues.jboss.org/browse/WFCORE-2567 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta10 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:39:00 2017 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Tue, 21 Mar 2017 13:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8353) Upgrade JBossWS from 5.1.7.Final to 5.1.8.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WFLY-8353: ---------------------------------- Fix Version/s: 11.0.0.Alpha1 > Upgrade JBossWS from 5.1.7.Final to 5.1.8.Final > ----------------------------------------------- > > Key: WFLY-8353 > URL: https://issues.jboss.org/browse/WFLY-8353 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Bartosz Spyrko-?mietanko > Assignee: Alessio Soldano > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 13:47:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 21 Mar 2017 13:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2568) Upgrade WildFly Elytron to 1.1.0.Beta31-SP1 In-Reply-To: References: Message-ID: Kabir Khan created WFCORE-2568: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta31-SP1 Key: WFCORE-2568 URL: https://issues.jboss.org/browse/WFCORE-2568 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta10 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 14:13:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Tue, 21 Mar 2017 14:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2163: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-2163 > URL: https://issues.jboss.org/browse/WFCORE-2163 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Priority: Critical > Fix For: 3.0.0.Beta11 > > > In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started. > I am using following configuration for HTTP management interface (see Steps to Reproduce for more details): > {code} > > > > > {code} > Server is not started and following errors occur in log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > 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.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided. > at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225) > at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254) > at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107) > at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589) > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292) > ... 5 more > {code} > and > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {code} > According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication. > [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJiSEGwI/edit# -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 14:42:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 14:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2566: ------------------------------- Description: Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String) was: Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} Tests will fail only if some next element follows - its parsing fails in such case correctly. Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta9 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. > Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 15:07:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 15:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1021) GSS mechanisms OIDs into OidsUtil In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina moved JBEAP-9749 to ELY-1021: ---------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1021 (was: JBEAP-9749) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Utils (was: Security) (was: User Experience) Affects Version/s: 1.1.0.Beta32 (was: 7.1.0.DR6) > GSS mechanisms OIDs into OidsUtil > --------------------------------- > > Key: ELY-1021 > URL: https://issues.jboss.org/browse/ELY-1021 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta32 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: eap71_beta, kerberos, management-model, model-review > > * {{mechanism-oids}} > ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} > ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. > * {{minimum-remaining-lifetime}} > ** please, specify units in documentation, e.g. seconds/minutes > * {{relative-to}} > ** as just path reference can be used here, probably should be just "expressions-allowed" => false > ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute." > * {{server}} > ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation. > * -{{for-hosts}}- > ** -comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?- -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 15:08:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 21 Mar 2017 15:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8415) Remove Elytron integration tests module from default build chain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved JBEAP-9750 to WFLY-8415: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8415 (was: JBEAP-9750) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System Test Suite (was: Build System) Affects Version/s: (was: 7.1.0.DR12) > Remove Elytron integration tests module from default build chain > ---------------------------------------------------------------- > > Key: WFLY-8415 > URL: https://issues.jboss.org/browse/WFLY-8415 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. > e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). > Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. > see http://pastebin.test.redhat.com/457432 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 15:42:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 21 Mar 2017 15:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381947#comment-13381947 ] Darran Lofthouse commented on WFCORE-2566: ------------------------------------------ [~honza889] I think in the short term we could possibly fix this while loop in the ElytronSubsystemParser {code:java} while (reader.hasNext() && reader.nextTag() != END_ELEMENT) { {code} Removing the reader.hasNext() check may be sufficient for the reader.nextTag to blow up if we have overshot and over parsed. > Subsystem parsing tests ignores wrong END_ELEMENT > ------------------------------------------------- > > Key: WFCORE-2566 > URL: https://issues.jboss.org/browse/WFCORE-2566 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta9 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code} > Tests will fail only if some next element follows - its parsing fails in such case correctly. > Would be better to add same check in the end of ** parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*. > Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed. > Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 16:17:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 21 Mar 2017 16:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-75) Fox Jenkins Solenium Suite Hang In-Reply-To: References: Message-ID: Matt Mahoney created HAWKULARQE-75: -------------------------------------- Summary: Fox Jenkins Solenium Suite Hang Key: HAWKULARQE-75 URL: https://issues.jboss.org/browse/HAWKULARQE-75 Project: Hawkular QE Issue Type: Task Environment: CF-UI suite hangs when running on Jenkins Selenium Server. Ref task Reporter: Matt Mahoney Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 16:20:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 21 Mar 2017 16:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-75) Fix Jenkins Solenium Suite Hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney reassigned HAWKULARQE-75: -------------------------------------- Summary: Fix Jenkins Solenium Suite Hang (was: Fox Jenkins Solenium Suite Hang) Environment: CF-UI suite hangs when running on Jenkins Selenium Server. Ref task: https://issues.jboss.org/browse/HAWKULARQE-45 was: CF-UI suite hangs when running on Jenkins Selenium Server. Ref task Assignee: Matt Mahoney (was: Michael Foley) > Fix Jenkins Solenium Suite Hang > ------------------------------- > > Key: HAWKULARQE-75 > URL: https://issues.jboss.org/browse/HAWKULARQE-75 > Project: Hawkular QE > Issue Type: Task > Environment: CF-UI suite hangs when running on Jenkins Selenium Server. > Ref task: https://issues.jboss.org/browse/HAWKULARQE-45 > Reporter: Matt Mahoney > Assignee: Matt Mahoney > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 16:21:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 21 Mar 2017 16:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-75) Fix Jenkins Solenium CF-UI Suite Hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-75: ----------------------------------- Summary: Fix Jenkins Solenium CF-UI Suite Hang (was: Fix Jenkins Solenium Suite Hang) > Fix Jenkins Solenium CF-UI Suite Hang > ------------------------------------- > > Key: HAWKULARQE-75 > URL: https://issues.jboss.org/browse/HAWKULARQE-75 > Project: Hawkular QE > Issue Type: Task > Environment: CF-UI suite hangs when running on Jenkins Selenium Server. > Ref task: https://issues.jboss.org/browse/HAWKULARQE-45 > Reporter: Matt Mahoney > Assignee: Matt Mahoney > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 16:24:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 16:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1021) GSS mechanisms OIDs into OidsUtil In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated ELY-1021: ---------------------------- Labels: eap71_beta kerberos (was: eap71_beta kerberos management-model model-review) > GSS mechanisms OIDs into OidsUtil > --------------------------------- > > Key: ELY-1021 > URL: https://issues.jboss.org/browse/ELY-1021 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta32 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: eap71_beta, kerberos > > * {{mechanism-oids}} > ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} > ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. > * {{minimum-remaining-lifetime}} > ** please, specify units in documentation, e.g. seconds/minutes > * {{relative-to}} > ** as just path reference can be used here, probably should be just "expressions-allowed" => false > ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute." > * {{server}} > ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation. > * -{{for-hosts}}- > ** -comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?- -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 16:24:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Tue, 21 Mar 2017 16:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1021) GSS mechanisms OIDs into OidsUtil In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated ELY-1021: ---------------------------- Description: * {{mechanism-oids}} ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. was: * {{mechanism-oids}} ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. * {{minimum-remaining-lifetime}} ** please, specify units in documentation, e.g. seconds/minutes * {{relative-to}} ** as just path reference can be used here, probably should be just "expressions-allowed" => false ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute." * {{server}} ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation. * -{{for-hosts}}- ** -comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?- > GSS mechanisms OIDs into OidsUtil > --------------------------------- > > Key: ELY-1021 > URL: https://issues.jboss.org/browse/ELY-1021 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta32 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: eap71_beta, kerberos > > * {{mechanism-oids}} > ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} > ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 17:11:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Tue, 21 Mar 2017 17:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: Carlo de Wolf created JBMETA-399: ------------------------------------ Summary: Metadata doesn't compile with Java 9 EA Key: JBMETA-399 URL: https://issues.jboss.org/browse/JBMETA-399 Project: JBoss Metadata Issue Type: Task Reporter: Carlo de Wolf {code} Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 9-ea, vendor: Oracle Corporation Java home: /opt/oracle/jdk-9-ea+161 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" {code} Results in: {code} $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package --------------------------------------------------- constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar constituent[3]: file:/usr/share/maven/lib/cdi-api.jar constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar constituent[11]: file:/usr/share/maven/lib/javax.inject.jar constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar constituent[15]: file:/usr/share/maven/lib/guava.jar constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar constituent[18]: file:/usr/share/maven/lib/commons-lang.jar constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar constituent[26]: file:/usr/share/maven/lib/commons-io.jar constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar constituent[28]: file:/usr/share/maven/lib/commons-cli.jar constituent[29]: file:/usr/share/maven/lib/wagon-file.jar constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar constituent[32]: file:/usr/share/maven/lib/aopalliance.jar constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar constituent[38]: file:/usr/share/maven/lib/guice.jar constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar constituent[40]: file:/usr/share/maven/lib/jsoup.jar constituent[41]: file:/usr/share/maven/conf/logging/ --------------------------------------------------- Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) at com.google.common.cache.LocalCache.get(LocalCache.java:3951) at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) at com.google.inject.internal.FailableCache.get(FailableCache.java:48) at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) at com.google.inject.Guice.createInjector(Guice.java:99) at com.google.inject.Guice.createInjector(Guice.java:73) at com.google.inject.Guice.createInjector(Guice.java:62) at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:547) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) ... 28 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 18:10:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 21 Mar 2017 18:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8416) Create BroadcastEndpoint implementation using WF clustering API In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-8416: ---------------------------------- Summary: Create BroadcastEndpoint implementation using WF clustering API Key: WFLY-8416 URL: https://issues.jboss.org/browse/WFLY-8416 Project: WildFly Issue Type: Task Components: Clustering, JMS Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 12.0.0.Alpha1 The upgrade to JGroups 4.0 will break the JGroups usage in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 18:11:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 21 Mar 2017 18:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8416) Create BroadcastEndpoint implementation using WF clustering API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-8416: ------------------------------- Description: The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. (was: The upgrade to JGroups 4.0 will break the JGroups usage in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage.) > Create BroadcastEndpoint implementation using WF clustering API > --------------------------------------------------------------- > > Key: WFLY-8416 > URL: https://issues.jboss.org/browse/WFLY-8416 > Project: WildFly > Issue Type: Task > Components: Clustering, JMS > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 18:12:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 21 Mar 2017 18:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8417) Create DistributedWorkManager implementation based on WF clustering API In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-8417: ---------------------------------- Summary: Create DistributedWorkManager implementation based on WF clustering API Key: WFLY-8417 URL: https://issues.jboss.org/browse/WFLY-8417 Project: WildFly Issue Type: Task Components: Clustering, JCA Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 12.0.0.Alpha1 The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x). JGroups is only used to broadcast/receive commands to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 01:52:00 2017 From: issues at jboss.org (Petr Kremensky (JIRA)) Date: Wed, 22 Mar 2017 01:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8415) Remove Elytron integration tests module from default build chain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kremensky updated WFLY-8415: --------------------------------- Description: Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. see http://pastebin.test.redhat.com/467005 was: Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. see http://pastebin.test.redhat.com/457432 > Remove Elytron integration tests module from default build chain > ---------------------------------------------------------------- > > Key: WFLY-8415 > URL: https://issues.jboss.org/browse/WFLY-8415 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. > e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). > Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. > see http://pastebin.test.redhat.com/467005 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 01:53:00 2017 From: issues at jboss.org (Petr Kremensky (JIRA)) Date: Wed, 22 Mar 2017 01:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8415) Remove Elytron integration tests module from default build chain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382041#comment-13382041 ] Petr Kremensky commented on WFLY-8415: -------------------------------------- [~ctomc] I can handle this one in case you're fine with http://pastebin.test.redhat.com/467005 > Remove Elytron integration tests module from default build chain > ---------------------------------------------------------------- > > Key: WFLY-8415 > URL: https://issues.jboss.org/browse/WFLY-8415 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them. > e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others). > Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property. > see http://pastebin.test.redhat.com/467005 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 03:38:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 22 Mar 2017 03:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2569) Elytron properties-realm is not able to read users dynamically In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2569: ------------------------------------ Summary: Elytron properties-realm is not able to read users dynamically Key: WFCORE-2569 URL: https://issues.jboss.org/browse/WFCORE-2569 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Elytron properties-realm reads users only during server start. As consequence it means that when Elytron properties-realm is used for securing management interface and user is added through {{add-user.sh}} script then authentication with that user is not possible until server is reloaded/restarted. In legacy security, users can be added and used without needed of reloading server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:08:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_Saka=C5=99_=28JIRA=29?=) Date: Wed, 22 Mar 2017 06:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8418) (7.1.0) Enhance the way licenses are presented and fix inconsistencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Saka? updated WFLY-8418: ----------------------------- Security: (was: Red Hat Internal) > (7.1.0) Enhance the way licenses are presented and fix inconsistencies > ---------------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: Petr Saka? > Assignee: Petr Saka? > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in EAP. > In addition we need to sanitize a bit the presented licensing information: > - License Names should adhere to the standard presented here: https://spdx.org/licenses/ (full license name). Apparently we present the same license using different names which can be confusing, e.g. The Apache Software License, Version 2.0, Apache Software License, Version 2.0, Apache License, Version 2.0, Apache 2, ASL 2.0 all refer essentially to Apache License 2.0 > > - The ActiveMQ package misses license name information, it should probably be Apache License 2.0. > - relaxngDatatype misses full license info > - Again, we shouldn't list simply "lgpl" > Some example is attached on the JIRA. > Licenses.html *MUST* contain a reference to the EAP version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one EAP release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:10:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_Saka=C5=99_=28JIRA=29?=) Date: Wed, 22 Mar 2017 06:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8418) (7.1.0) Enhance the way licenses are presented and fix inconsistencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Saka? updated WFLY-8418: ----------------------------- Description: We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. In addition we need to sanitize a bit the presented licensing information: Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. was: We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in EAP. In addition we need to sanitize a bit the presented licensing information: - License Names should adhere to the standard presented here: https://spdx.org/licenses/ (full license name). Apparently we present the same license using different names which can be confusing, e.g. The Apache Software License, Version 2.0, Apache Software License, Version 2.0, Apache License, Version 2.0, Apache 2, ASL 2.0 all refer essentially to Apache License 2.0 - The ActiveMQ package misses license name information, it should probably be Apache License 2.0. - relaxngDatatype misses full license info - Again, we shouldn't list simply "lgpl" Some example is attached on the JIRA. Licenses.html *MUST* contain a reference to the EAP version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one EAP release cycle. > (7.1.0) Enhance the way licenses are presented and fix inconsistencies > ---------------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: Petr Saka? > Assignee: Petr Saka? > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. > In addition we need to sanitize a bit the presented licensing information: > Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:13:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 22 Mar 2017 06:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1491) It is not possible for a type declaration to extend a Java class In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1491: ----------------------------------- Summary: It is not possible for a type declaration to extend a Java class Key: DROOLS-1491 URL: https://issues.jboss.org/browse/DROOLS-1491 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:20:00 2017 From: issues at jboss.org (=?UTF-8?Q?Petr_Saka=C5=99_=28JIRA=29?=) Date: Wed, 22 Mar 2017 06:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8418) Enhance the way licenses are presented and fix inconsistencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Saka? updated WFLY-8418: ----------------------------- Summary: Enhance the way licenses are presented and fix inconsistencies (was: (7.1.0) Enhance the way licenses are presented and fix inconsistencies) > Enhance the way licenses are presented and fix inconsistencies > -------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: Petr Saka? > Assignee: Petr Saka? > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. > In addition we need to sanitize a bit the presented licensing information: > Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:27:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 06:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2391) No log messages comming from Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382180#comment-13382180 ] Ingo Weiss commented on WFCORE-2391: ------------------------------------ I think this has been worked on by others during Elytron's development and should be closed. WDYT [~dlofthouse], [~jcacek]? > No log messages comming from Elytron > ------------------------------------ > > Key: WFCORE-2391 > URL: https://issues.jboss.org/browse/WFCORE-2391 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:28:01 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 06:28:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382182#comment-13382182 ] Ingo Weiss commented on WFLY-8228: ---------------------------------- This has been fixed on https://github.com/wildfly-security-incubator/wildfly/pull/144. > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: No Release > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:28:01 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Wed, 22 Mar 2017 06:28:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8418) Enhance the way licenses are presented and fix inconsistencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFLY-8418: ----------------------------- Affects Version/s: (was: 11.0.0.Alpha1) > Enhance the way licenses are presented and fix inconsistencies > -------------------------------------------------------------- > > Key: WFLY-8418 > URL: https://issues.jboss.org/browse/WFLY-8418 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Petr Saka? > Assignee: Petr Saka? > Priority: Critical > Labels: downstream_dependency > > We need to provide a better view of the existing license information presented in the docs/licenses.xml file, in the form of a docs/licenses.html file that lists: > Group/Artifact/Version/License (name+original URL)/Local Copy(relative pathname link to local copy of the license in the licenses dir). > This can be achieved with an .xslt transformation that runs as part of the build process, which produces the desired licenses.html, and it would allow us to zip and forward the entire doc/licenses directory to a client that wants to evaluate the licenses used in Wildfly. > In addition we need to sanitize a bit the presented licensing information: > Licenses.html *MUST* contain a reference to the Wildfly version it applies to. It *MUST* also contain a timestamp (or build number) to uniquely identify it should it need changes within one Wildfly release cycle. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 06:28:02 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 06:28:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss closed WFLY-8228. ---------------------------- Fix Version/s: No Release Resolution: Done > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: No Release > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:05:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 22 Mar 2017 07:05:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2569) Elytron properties-realm is not able to read users dynamically In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas closed WFCORE-2569. -------------------------------- Resolution: Duplicate Issue > Elytron properties-realm is not able to read users dynamically > -------------------------------------------------------------- > > Key: WFCORE-2569 > URL: https://issues.jboss.org/browse/WFCORE-2569 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron properties-realm reads users only during server start. As consequence it means that when Elytron properties-realm is used for securing management interface and user is added through {{add-user.sh}} script then authentication with that user is not possible until server is reloaded/restarted. In legacy security, users can be added and used without needed of reloading server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:06:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Wed, 22 Mar 2017 07:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2444) There isn't possibility log in to management web console as user which was dynamically added after EAP was started. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2444: --------------------------------- Priority: Critical (was: Major) > There isn't possibility log in to management web console as user which was dynamically added after EAP was started. > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2444 > URL: https://issues.jboss.org/browse/WFCORE-2444 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Critical > > I am not able to log in to management web console as user which was dynamically added after EAP was started. > *Scenario:* > * EAP is running - *standalone.sh -c=standalone-elytron.xml* > * add user through script *add-user.sh -u john -p password1! -s* > * log in to management web console as user *john* > *Result:* > * It doesn't work until restart > When we use Picketbox then it works fine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:06:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 07:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2391) No log messages comming from Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382205#comment-13382205 ] Darran Lofthouse commented on WFCORE-2391: ------------------------------------------ +1 I think in general we do have log message now. We probably do have areas to add to but I think we will need specific issues to cover those i.e. in scenario X it failed but the log did not reveal anything useful. > No log messages comming from Elytron > ------------------------------------ > > Key: WFCORE-2391 > URL: https://issues.jboss.org/browse/WFCORE-2391 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Critical > > Elytron functionality is not covered (sufficiently) by log messages. > The log messages are cornerstone for customers when they're investigating configuration or functional issues. > Even when enabling {{TRACE}} log-level I was seeing No log messages coming from Elytron when I was configuring web authentication. When authentication fails it's not clear what's wrong - if password is invalid or permission mapper doesn't work or something else happened. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:09:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 22 Mar 2017 07:09:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2428) Properties of Elytron dir-context are parsed incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reassigned WFCORE-2428: ---------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Properties of Elytron dir-context are parsed incorrectly > -------------------------------------------------------- > > Key: WFCORE-2428 > URL: https://issues.jboss.org/browse/WFCORE-2428 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > Properties added for Elytron {{dir-context}} through server configuration are parsed incorrectly. In case when some value is used in server configuration then its representation in server obtains also quotation marks, i.e. {{something}} is parsed as string {{"something"}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:29:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 07:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7011) Missing https://github.com/wildfly/wildfly-capabilities entry for capability org.wildfly.undertow.listener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382225#comment-13382225 ] Ingo Weiss commented on WFLY-7011: ---------------------------------- [~brian.stansberry], I think this can be closed in favour of https://issues.jboss.org/browse/WFLY-7442. > Missing https://github.com/wildfly/wildfly-capabilities entry for capability org.wildfly.undertow.listener > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-7011 > URL: https://issues.jboss.org/browse/WFLY-7011 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Brian Stansberry > Assignee: Ingo Weiss > > The contract for this capability needs examination and recording in the registry. > Note that the task here is not to just create a meaningless entry. Once the entry is published a contract is established, so the contract has to be correct. ListenerService doesn't look like a good API to be exposed to external callers; it exposes details that probably should not be part of a contract. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:39:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 22 Mar 2017 07:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2428) Properties of Elytron dir-context are parsed incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382236#comment-13382236 ] Jan Kalina commented on WFCORE-2428: ------------------------------------ This was already fixed as part of WFLY-7843 > Properties of Elytron dir-context are parsed incorrectly > -------------------------------------------------------- > > Key: WFCORE-2428 > URL: https://issues.jboss.org/browse/WFCORE-2428 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > Properties added for Elytron {{dir-context}} through server configuration are parsed incorrectly. In case when some value is used in server configuration then its representation in server obtains also quotation marks, i.e. {{something}} is parsed as string {{"something"}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 07:48:00 2017 From: issues at jboss.org (=?UTF-8?Q?Mario_Garc=C3=ADa_Garc=C3=ADa_=28JIRA=29?=) Date: Wed, 22 Mar 2017 07:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8358) Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Garc?a Garc?a updated WFLY-8358: -------------------------------------- Description: Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as '?'. This is the String that is sent into a parameter: "C?digo" No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8'). The received parameter in HttpServletRequest (doPost method) is showed like this: "C??digo". In Hex this is the content: 43 3f3f 6469676f (spaces added for better reading pourposes) This is not UTF-8. The proper encoding should be: 43 c3b3 6469676f (spaces added for better reading pourposes) Wildfly Configuration: Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP Default encoding: (empty) Java encoding: UTF8 Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP Url charset: UTF-8 was: Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as '?'. This is the String that is sent into a parameter: "C?digo" No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8'). The received parameter in HttpServletRequest (doPost method) is showed like this: "C??digo". In Hex this is the content: 43 3f3f 6469676f (spaces added for better reading pourposes) This is no UTF-8. The proper encoding should be: 43 c3b3 6469676f (spaces added for better reading pourposes) Wildfly Configuration: Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP Default encoding: (empty) Java encoding: UTF8 Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP Url charset: UTF-8 > Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX > --------------------------------------------------------------------------------- > > Key: WFLY-8358 > URL: https://issues.jboss.org/browse/WFLY-8358 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.1.0.Final > Environment: Tested in Windows 7 Enterprise and tested in Linux 3.16.6-2-desktop > Reporter: Mario Garc?a Garc?a > Assignee: Jason Greene > Attachments: MiServlet.java, index.jsp > > > Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as '?'. > This is the String that is sent into a parameter: > "C?digo" > No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8'). > The received parameter in HttpServletRequest (doPost method) is showed like this: > "C??digo". > In Hex this is the content: > 43 3f3f 6469676f (spaces added for better reading pourposes) > This is not UTF-8. The proper encoding should be: > 43 c3b3 6469676f (spaces added for better reading pourposes) > Wildfly Configuration: > Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP > Default encoding: (empty) > Java encoding: UTF8 > Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP > Url charset: UTF-8 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:20:01 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 22 Mar 2017 08:20:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2396) credential-store and authentication-context in Elytron dir-context should be mutually exclusive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reassigned WFCORE-2396: ---------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > credential-store and authentication-context in Elytron dir-context should be mutually exclusive > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2396 > URL: https://issues.jboss.org/browse/WFCORE-2396 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > To avoid possibility when two different credentials are configured in Elytron dir-context, its attributes credential-store and authentication-context should be mutually exclusive. > This jira is based on discussion in JBEAP-8026. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:27:01 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 22 Mar 2017 08:27:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1022) Elytron Audit Logging does not support sending messages over TLS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel reassigned ELY-1022: ------------------------------ Assignee: (was: Darran Lofthouse) > Elytron Audit Logging does not support sending messages over TLS > ---------------------------------------------------------------- > > Key: ELY-1022 > URL: https://issues.jboss.org/browse/ELY-1022 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Blocker > > Currently, Elytron Audit Logging supports only UDP and TCP transport protocols for sending messages to Syslog server. There should be a possibility to send messages over TLS as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:27:01 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Wed, 22 Mar 2017 08:27:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1022) Elytron Audit Logging does not support sending messages over TLS In-Reply-To: References: Message-ID: Jan Tymel created ELY-1022: ------------------------------ Summary: Elytron Audit Logging does not support sending messages over TLS Key: ELY-1022 URL: https://issues.jboss.org/browse/ELY-1022 Project: WildFly Elytron Issue Type: Bug Reporter: Jan Tymel Assignee: Darran Lofthouse Priority: Blocker Currently, Elytron Audit Logging supports only UDP and TCP transport protocols for sending messages to Syslog server. There should be a possibility to send messages over TLS as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:27:02 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 08:27:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2486) Legacy ldap realm returns 401 if LDAP is unreachable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2486: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Legacy ldap realm returns 401 if LDAP is unreachable > ---------------------------------------------------- > > Key: WFCORE-2486 > URL: https://issues.jboss.org/browse/WFCORE-2486 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta11 > > > Contradics JBEAP-8125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:31:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 08:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2438) Legacy Kerberos for management interface returns 500 instead of 401 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2438: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 4.0.0.Alpha1) > Legacy Kerberos for management interface returns 500 instead of 401 > ------------------------------------------------------------------- > > Key: WFCORE-2438 > URL: https://issues.jboss.org/browse/WFCORE-2438 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta11 > > > On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case. > Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages > {code:title=server.log} > 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:32:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 08:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2386: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta11 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > Error401 - Unauthorized > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > Error401 - Unauthorized > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:32:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 08:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2386: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 3.0.0.Beta10) > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta11 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > Error401 - Unauthorized > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > Error401 - Unauthorized > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:33:01 2017 From: issues at jboss.org (Dmitrii Tikhomirov (JIRA)) Date: Wed, 22 Mar 2017 08:33:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2456) Obtain password from external source (CMD, EXT) doesn't work on Windows. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitrii Tikhomirov reassigned WFCORE-2456: ------------------------------------------ Assignee: Dmitrii Tikhomirov (was: Darran Lofthouse) > Obtain password from external source (CMD, EXT) doesn't work on Windows. > ------------------------------------------------------------------------ > > Key: WFCORE-2456 > URL: https://issues.jboss.org/browse/WFCORE-2456 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Dmitrii Tikhomirov > > Obtain password from external source (CMD, EXT) doesn't work on Windows. > Try to create new CS which obtains password from external source: > {code} > /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) > {code} > pass.bat file contains only this > {code} > echo %1 > {code} > Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: > Add new alias to CS -> JCEKS file is created > Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. > In my opinion there is problem with back slashes in script path. > https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src/main/java/org/jboss/as/controller/security/CredentialReference.java#L198 > Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:41:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1023) Use authentication context to obtain additional credentials from callback handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor reassigned ELY-1023: ------------------------------- Assignee: Pedro Igor (was: Darran Lofthouse) > Use authentication context to obtain additional credentials from callback handlers > ---------------------------------------------------------------------------------- > > Key: ELY-1023 > URL: https://issues.jboss.org/browse/ELY-1023 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:41:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1023) Use authentication context in OAuth2CredentialSource to obtain additional credentials a callback handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated ELY-1023: ---------------------------- Summary: Use authentication context in OAuth2CredentialSource to obtain additional credentials a callback handler (was: Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers) > Use authentication context in OAuth2CredentialSource to obtain additional credentials a callback handler > -------------------------------------------------------------------------------------------------------- > > Key: ELY-1023 > URL: https://issues.jboss.org/browse/ELY-1023 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:41:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1023) Use authentication context to obtain additional credentials from callback handlers In-Reply-To: References: Message-ID: Pedro Igor created ELY-1023: ------------------------------- Summary: Use authentication context to obtain additional credentials from callback handlers Key: ELY-1023 URL: https://issues.jboss.org/browse/ELY-1023 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Client Affects Versions: 1.1.0.Beta32 Reporter: Pedro Igor Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:41:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 08:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1023) Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated ELY-1023: ---------------------------- Summary: Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers (was: Use authentication context to obtain additional credentials from callback handlers) > Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers > ------------------------------------------------------------------------------------------------------------ > > Key: ELY-1023 > URL: https://issues.jboss.org/browse/ELY-1023 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:42:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 08:42:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2384) Elytron subsystem is unable to configure com.sun.net.ssl.internal.ssl.Provider in FIPS mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2384: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Elytron subsystem is unable to configure com.sun.net.ssl.internal.ssl.Provider in FIPS mode > ------------------------------------------------------------------------------------------- > > Key: WFCORE-2384 > URL: https://issues.jboss.org/browse/WFCORE-2384 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta11 > > > Trying to configure server to run in FIPS mode using subsystem capabilities. > I can't configure throught subsystem same as in java.security file: > {code:title=java.security} > security.provider.5=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-testPkcs > {code} > because there is no possibility in subsystem to call provider constructor with arguments (I don't mean providers configuration) > Subsystem implements provider loading in 2 steps > * create provider instance (call noargs constructor) > * optionally load configuration > But to create {{com.sun.net.ssl.internal.ssl.Provider}} in FIPS mode constructor with arguments must be called [1] > [1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/net/ssl/internal/ssl/Provider.java#49 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:42:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 22 Mar 2017 08:42:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2383) Elytron subsystem is unable to configure SunPKCS11 provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2383: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 4.0.0.Alpha1) > Elytron subsystem is unable to configure SunPKCS11 provider > ----------------------------------------------------------- > > Key: WFCORE-2383 > URL: https://issues.jboss.org/browse/WFCORE-2383 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta11 > > > Trying to configure server to run in FIPS mode using subsystem capabilities. > I can't configure throught subsystem same as in java.security file: > {code:title=java.security} > security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/pkcs11.cfg > {code} > because if I try to pass configuration file or configuration > {code} > /subsystem=elytron/provider-loader=fips:add(class-names=[sun.security.pkcs11.SunPKCS11], path=/usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/pkcs11.cfg) > /subsystem=elytron/provider-loader=fips:add(class-names=[sun.security.pkcs11.SunPKCS11], configuration={ \ > name=nssModule, value=fips \ > name=nssSecmodDirectory, value=/usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/fipsdb \ > name=nssLibraryDirectory, value=/usr/lib64 \ > name=name, value=testPkcs \ > name=nssDbMode, value=readOnly \ > } > {code} > I get exception > {code} > 10:46:28,630 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.providers.fips: org.jboss.msc.service.StartException in service org.wildfly.security.providers.fips: java.security.ProviderException: SunPKCS11 requires configuration file argument > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:185) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:143) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.ProviderException: SunPKCS11 requires configuration file argument > at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:98) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at java.lang.Class.newInstance(Class.java:442) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:156) > ... 7 more > 10:46:28,630 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("provider-loader" => "fips") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.fips" => "org.jboss.msc.service.StartException in service org.wildfly.security.providers.fips: java.security.ProviderException: SunPKCS11 requires configuration file argument > Caused by: java.security.ProviderException: SunPKCS11 requires configuration file argument"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.providers.fips"] > } > {code} > It occures because loading of providers is in subsystem implemented in 2 steps > * create provider instance (call noargs constructor) > * optionally load configuration > But {{sun.security.pkcs11.SunPKCS11}} can't be created without configuration [1] > [1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/security/pkcs11/SunPKCS11.java#98 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:43:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 22 Mar 2017 08:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8419) poll pool stats in loop instead of Thread.sleep in AbstractDatasourceCapacityPoliciesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka moved JBEAP-9772 to WFLY-8419: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8419 (was: JBEAP-9772) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.1.0.DR14) > poll pool stats in loop instead of Thread.sleep in AbstractDatasourceCapacityPoliciesTestCase > --------------------------------------------------------------------------------------------- > > Key: WFLY-8419 > URL: https://issues.jboss.org/browse/WFLY-8419 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Martin Simka > Assignee: Martin Simka > Priority: Trivial > > There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/capacitypolicies/AbstractDatasourceCapacityPoliciesTestCase.java#L130] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 08:44:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 08:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1023) Use authentication context in OAuth2CredentialSource to obtain additional credentials a callback handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated ELY-1023: ---------------------------- Description: Currently, all required credentials (client/user) for {{OAuth2CredentialSource}} should come from the configuration file. In some cases, we may want to obtain these credentials using a callback handler provided during runtime. On use case for this is how authentication in CLI stands today, where users can be prompted for their credentials. > Use authentication context in OAuth2CredentialSource to obtain additional credentials a callback handler > -------------------------------------------------------------------------------------------------------- > > Key: ELY-1023 > URL: https://issues.jboss.org/browse/ELY-1023 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > > Currently, all required credentials (client/user) for {{OAuth2CredentialSource}} should come from the configuration file. > In some cases, we may want to obtain these credentials using a callback handler provided during runtime. On use case for this is how authentication in CLI stands today, where users can be prompted for their credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 09:33:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 22 Mar 2017 09:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2570) Explain the meaning of maximum-session-cache-size and session-timeout default values. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev moved JBEAP-9781 to WFCORE-2570: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2570 (was: JBEAP-9781) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR14) > Explain the meaning of maximum-session-cache-size and session-timeout default values. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2570 > URL: https://issues.jboss.org/browse/WFCORE-2570 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > > The default values 0 of maximum-session-cache-size and session-timeout of Elytron will not override the JVM defaults. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:02:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 10:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown roles instead of throwing exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor reassigned WFCORE-2071: ---------------------------------- Assignee: Pedro Igor (was: Darran Lofthouse) > Properly handle unknown roles instead of throwing exception > ----------------------------------------------------------- > > Key: WFCORE-2071 > URL: https://issues.jboss.org/browse/WFCORE-2071 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 3.0.0.Beta11 > > > When mapping roles directly from the identity: > {code} > > {code} > If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. > Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:05:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 22 Mar 2017 10:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8420) Missing dependencies from wildfly-naming-client In-Reply-To: References: Message-ID: David Lloyd created WFLY-8420: --------------------------------- Summary: Missing dependencies from wildfly-naming-client Key: WFLY-8420 URL: https://issues.jboss.org/browse/WFLY-8420 Project: WildFly Issue Type: Bug Components: Naming Reporter: David Lloyd Assignee: David Lloyd This module is missing service dependencies on the EJB client and the transaction client, both of which register context handlers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:06:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 22 Mar 2017 10:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8419) poll pool stats in loop instead of Thread.sleep in AbstractDatasourceCapacityPoliciesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka updated WFLY-8419: ------------------------------- Description: There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/capacitypolicies/AbstractDatasourceCapacityPoliciesTestCase.java#L130] and [ResourceAdapterCapacityPoliciesTestCase.java#L148|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/capacitypolicies/ResourceAdapterCapacityPoliciesTestCase.java#L148] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout (was: There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/capacitypolicies/AbstractDatasourceCapacityPoliciesTestCase.java#L130] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout) > poll pool stats in loop instead of Thread.sleep in AbstractDatasourceCapacityPoliciesTestCase > --------------------------------------------------------------------------------------------- > > Key: WFLY-8419 > URL: https://issues.jboss.org/browse/WFLY-8419 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Martin Simka > Assignee: Martin Simka > Priority: Trivial > > There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/capacitypolicies/AbstractDatasourceCapacityPoliciesTestCase.java#L130] and [ResourceAdapterCapacityPoliciesTestCase.java#L148|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/capacitypolicies/ResourceAdapterCapacityPoliciesTestCase.java#L148] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:07:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 22 Mar 2017 10:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2570) Explain the meaning of maximum-session-cache-size and session-timeout default values. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev updated WFCORE-2570: ---------------------------------- Affects Version/s: 3.0.0.Beta9 > Explain the meaning of maximum-session-cache-size and session-timeout default values. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2570 > URL: https://issues.jboss.org/browse/WFCORE-2570 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > > The default values 0 of maximum-session-cache-size and session-timeout of Elytron will not override the JVM defaults. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:17:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 22 Mar 2017 10:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1024) Match rules do not allow matching any-or-no user In-Reply-To: References: Message-ID: David Lloyd created ELY-1024: -------------------------------- Summary: Match rules do not allow matching any-or-no user Key: ELY-1024 URL: https://issues.jboss.org/browse/ELY-1024 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:22:01 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 10:22:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Ignore unknown roles instead of throwing exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated WFCORE-2071: ------------------------------- Summary: Ignore unknown roles instead of throwing exception (was: Properly handle unknown roles instead of throwing exception) > Ignore unknown roles instead of throwing exception > -------------------------------------------------- > > Key: WFCORE-2071 > URL: https://issues.jboss.org/browse/WFCORE-2071 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 3.0.0.Beta11 > > > When mapping roles directly from the identity: > {code} > > {code} > If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. > Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:31:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 22 Mar 2017 10:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics In-Reply-To: References: Message-ID: Martin Simka created JBJCA-1344: ----------------------------------- Summary: race condition between PoolFiller and CapacityFiller results in wrong pool statistics Key: JBJCA-1344 URL: https://issues.jboss.org/browse/JBJCA-1344 Project: IronJacamar Issue Type: Bug Reporter: Martin Simka Attachments: fail.log, pass.log There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics I think what happens is: - Both add connections to pool in different threads - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:32:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 22 Mar 2017 10:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1345) race condition between PoolFiller and CapacityFiller results in wrong pool statistics In-Reply-To: References: Message-ID: Martin Simka created JBJCA-1345: ----------------------------------- Summary: race condition between PoolFiller and CapacityFiller results in wrong pool statistics Key: JBJCA-1345 URL: https://issues.jboss.org/browse/JBJCA-1345 Project: IronJacamar Issue Type: Bug Reporter: Martin Simka There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics I think what happens is: - Both add connections to pool in different threads - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:33:00 2017 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Wed, 22 Mar 2017 10:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri reassigned JBJCA-1344: -------------------------------------- Assignee: Flavia Rainone > race condition between PoolFiller and CapacityFiller results in wrong pool statistics > ------------------------------------------------------------------------------------- > > Key: JBJCA-1344 > URL: https://issues.jboss.org/browse/JBJCA-1344 > Project: IronJacamar > Issue Type: Bug > Reporter: Martin Simka > Assignee: Flavia Rainone > Attachments: fail.log, pass.log > > > There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:34:01 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 22 Mar 2017 10:34:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka reassigned JBJCA-1344: ----------------------------------- Affects Version/s: WildFly/IronJacamar 1.4.2.Final Assignee: (was: Flavia Rainone) > race condition between PoolFiller and CapacityFiller results in wrong pool statistics > ------------------------------------------------------------------------------------- > > Key: JBJCA-1344 > URL: https://issues.jboss.org/browse/JBJCA-1344 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.2.Final > Reporter: Martin Simka > Attachments: fail.log, pass.log > > > There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 10:38:01 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 22 Mar 2017 10:38:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka reassigned JBJCA-1344: ----------------------------------- Assignee: Flavia Rainone > race condition between PoolFiller and CapacityFiller results in wrong pool statistics > ------------------------------------------------------------------------------------- > > Key: JBJCA-1344 > URL: https://issues.jboss.org/browse/JBJCA-1344 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.2.Final > Reporter: Martin Simka > Assignee: Flavia Rainone > Attachments: fail.log, pass.log > > > There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 11:22:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Wed, 22 Mar 2017 11:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1492) DecisionTable to perform typeRef allowed values check for input and output clause In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1492: -------------------------------------- Summary: DecisionTable to perform typeRef allowed values check for input and output clause Key: DROOLS-1492 URL: https://issues.jboss.org/browse/DROOLS-1492 Project: Drools Issue Type: Feature Request Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Example model {code:xml} feel:string "a","b","c" MyInput - "Decision taken" {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 11:37:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 22 Mar 2017 11:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-923) Elytron caching-realm backed by ldap-realm should avoid hitting LDAP for a cache hit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek updated ELY-923: ----------------------------- Summary: Elytron caching-realm backed by ldap-realm should avoid hitting LDAP for a cache hit (was: Elytron LDAP caching realm should cache attributes and credentials) > Elytron caching-realm backed by ldap-realm should avoid hitting LDAP for a cache hit > ------------------------------------------------------------------------------------ > > Key: ELY-923 > URL: https://issues.jboss.org/browse/ELY-923 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta21 > Reporter: Ondrej Kotek > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta28 > > > Elytron {{caching-realm}} backed by {{ldap-realm}} provides caching for identity objects but not for related credentials and attributes. This is currently due to design of {{ldap-realm}} (like in case of {{filesystem-realm}}, see ELY-915). > Credentials and attributes should not be loaded from LDAP for a cache hit. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 11:53:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 11:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1025) Provide a Bearet Token HTTP Authentication Mechanism In-Reply-To: References: Message-ID: Pedro Igor created ELY-1025: ------------------------------- Summary: Provide a Bearet Token HTTP Authentication Mechanism Key: ELY-1025 URL: https://issues.jboss.org/browse/ELY-1025 Project: WildFly Elytron Issue Type: Feature Request Components: HTTP Affects Versions: 1.1.0.Beta32 Reporter: Pedro Igor Assignee: Pedro Igor Provide a HTTP mechanisms capable of authenticating requests using a bearer token. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 11:53:01 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 11:53:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1025) Provide a Bearer Token HTTP Authentication Mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated ELY-1025: ---------------------------- Summary: Provide a Bearer Token HTTP Authentication Mechanism (was: Provide a Bearet Token HTTP Authentication Mechanism) > Provide a Bearer Token HTTP Authentication Mechanism > ---------------------------------------------------- > > Key: ELY-1025 > URL: https://issues.jboss.org/browse/ELY-1025 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > > Provide a HTTP mechanisms capable of authenticating requests using a bearer token. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:12:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 12:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1025) Provide a Bearer Token HTTP Authentication Mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated ELY-1025: ---------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/739, https://github.com/wildfly-security/elytron-web/pull/89 (was: https://github.com/wildfly-security/wildfly-elytron/pull/739) > Provide a Bearer Token HTTP Authentication Mechanism > ---------------------------------------------------- > > Key: ELY-1025 > URL: https://issues.jboss.org/browse/ELY-1025 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > > Provide a HTTP mechanisms capable of authenticating requests using a bearer token. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:13:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 12:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1023) Use authentication context in OAuth2CredentialSource to obtain additional credentials from a callback handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated ELY-1023: ---------------------------- Summary: Use authentication context in OAuth2CredentialSource to obtain additional credentials from a callback handler (was: Use authentication context in OAuth2CredentialSource to obtain additional credentials a callback handler) > Use authentication context in OAuth2CredentialSource to obtain additional credentials from a callback handler > ------------------------------------------------------------------------------------------------------------- > > Key: ELY-1023 > URL: https://issues.jboss.org/browse/ELY-1023 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > > Currently, all required credentials (client/user) for {{OAuth2CredentialSource}} should come from the configuration file. > In some cases, we may want to obtain these credentials using a callback handler provided during runtime. On use case for this is how authentication in CLI stands today, where users can be prompted for their credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:21:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 22 Mar 2017 12:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382519#comment-13382519 ] Brian Stansberry commented on WFLY-8228: ---------------------------------------- Why Closed with No Release instead of Resolved with 11.0.0.Alpha1? > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: No Release > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:24:01 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 12:24:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8228: ----------------------------- Fix Version/s: 11.0.0.Alpha1 (was: No Release) > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:24:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 12:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss reopened WFLY-8228: ------------------------------ > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:25:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 12:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382521#comment-13382521 ] Ingo Weiss commented on WFLY-8228: ---------------------------------- My mistake. Let me resolve it. > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:26:01 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 22 Mar 2017 12:26:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss resolved WFLY-8228. ------------------------------ Resolution: Done > Servlet server distribution fails to work with Elytron - NoClassDefFoundError > ----------------------------------------------------------------------------- > > Key: WFLY-8228 > URL: https://issues.jboss.org/browse/WFLY-8228 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ingo Weiss > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > Original Estimate: 1 day > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails. > Sample output: > {code} > 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91) > at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42) > at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104) > at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43) > at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56) > at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35) > at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588) > at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595) > at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727) > at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450) > at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:84) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:28:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 22 Mar 2017 12:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8421) Upgrade jboss-ejb-client to 4.0.0.Beta22 In-Reply-To: References: Message-ID: Farah Juma created WFLY-8421: -------------------------------- Summary: Upgrade jboss-ejb-client to 4.0.0.Beta22 Key: WFLY-8421 URL: https://issues.jboss.org/browse/WFLY-8421 Project: WildFly Issue Type: Component Upgrade Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:34:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 22 Mar 2017 12:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-76) Add Provider - Security Protocol In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-76: ---------------------------------------- Summary: Add Provider - Security Protocol Key: HAWKULARQE-76 URL: https://issues.jboss.org/browse/HAWKULARQE-76 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley Priority: Critical In Add New Provider page there is a new field: "Security Protocol", for validating connection. It needs to be tested and automated in Provider CRUD tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:35:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 22 Mar 2017 12:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-77) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-77: ---------------------------------------- Summary: Manual Testcases - Create and Run Key: HAWKULARQE-77 URL: https://issues.jboss.org/browse/HAWKULARQE-77 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Michael Foley Priority: Critical -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:35:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 22 Mar 2017 12:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-78) Automate Testcases In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-78: ---------------------------------------- Summary: Automate Testcases Key: HAWKULARQE-78 URL: https://issues.jboss.org/browse/HAWKULARQE-78 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Michael Foley Priority: Critical -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:53:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 22 Mar 2017 12:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2409) Review elytron kerberos-security-factory resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382542#comment-13382542 ] Jan Kalina commented on WFCORE-2409: ------------------------------------ Resolved in PR92, except this point: *server* > Review elytron kerberos-security-factory resource > ------------------------------------------------- > > Key: WFCORE-2409 > URL: https://issues.jboss.org/browse/WFCORE-2409 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > * {{mechanism-oids}} > ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} > ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. > * {{minimum-remaining-lifetime}} > ** please, specify units in documentation, e.g. seconds/minutes > * {{relative-to}} > ** as just path reference can be used here, probably should be just "expressions-allowed" => false > ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute." > * {{server}} > ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation. > * {{for-hosts}} > ** comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 12:59:01 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 12:59:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2571) Support Bearer Token Credential type in CLI In-Reply-To: References: Message-ID: Pedro Igor created WFCORE-2571: ---------------------------------- Summary: Support Bearer Token Credential type in CLI Key: WFCORE-2571 URL: https://issues.jboss.org/browse/WFCORE-2571 Project: WildFly Core Issue Type: Enhancement Components: CLI Affects Versions: 3.0.0.Beta10 Reporter: Pedro Igor Assignee: Pedro Igor CLI should be able to support bearer token credentials in order to support integration with OAuth2 and OpenID Connect compliant authorization servers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 13:14:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 22 Mar 2017 13:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1490) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382548#comment-13382548 ] Mario Fusco commented on DROOLS-1490: ------------------------------------- Implemented in core with https://github.com/kiegroup/drools/commit/ab5ee72736f3418c2344654a58eb326c37650d73 > Improve temporal operators to support java.time classes > ------------------------------------------------------- > > Key: DROOLS-1490 > URL: https://issues.jboss.org/browse/DROOLS-1490 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: chandra vudumula > Assignee: Mario Fusco > Attachments: image-2017-03-20-11-45-20-413.png > > > Hi, > I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. > but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... > Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 13:43:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 22 Mar 2017 13:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1493) Improve temporal operators to support java.time classes In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1493: ----------------------------------- Summary: Improve temporal operators to support java.time classes Key: DROOLS-1493 URL: https://issues.jboss.org/browse/DROOLS-1493 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.0.0.Beta7 Reporter: chandra vudumula Assignee: Mario Fusco Attachments: image-2017-03-20-11-45-20-413.png Hi, I am trying to create a rule using UI,i have a filed LocalDateTime have to compare using after or before. but in UI i am unable to see those options, its just showing default options like :equal to", "not equal to"... Added dependencies in sourceObject and didnt helped -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 13:51:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Wed, 22 Mar 2017 13:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2571) Enable OAUTH_BEARER SASL mechanism to CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated WFCORE-2571: ------------------------------- Summary: Enable OAUTH_BEARER SASL mechanism to CLI (was: Support Bearer Token Credential type in CLI) > Enable OAUTH_BEARER SASL mechanism to CLI > ----------------------------------------- > > Key: WFCORE-2571 > URL: https://issues.jboss.org/browse/WFCORE-2571 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Affects Versions: 3.0.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > > CLI should be able to support bearer token credentials in order to support integration with OAuth2 and OpenID Connect compliant authorization servers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 18:19:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 22 Mar 2017 18:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8416) Create BroadcastEndpoint implementation using WF clustering API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-8416: ------------------------------- Description: The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage as well as abstract away concepts like fork channels, etc. (was: The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage.) > Create BroadcastEndpoint implementation using WF clustering API > --------------------------------------------------------------- > > Key: WFLY-8416 > URL: https://issues.jboss.org/browse/WFLY-8416 > Project: WildFly > Issue Type: Task > Components: Clustering, JMS > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x). JGroups is only used to broadcast/receive a byte[] to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage as well as abstract away concepts like fork channels, etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 20:37:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 22 Mar 2017 20:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8423) Transaction client does not have access to EJB client In-Reply-To: References: Message-ID: David Lloyd created WFLY-8423: --------------------------------- Summary: Transaction client does not have access to EJB client Key: WFLY-8423 URL: https://issues.jboss.org/browse/WFLY-8423 Project: WildFly Issue Type: Bug Components: Build System Reporter: David Lloyd Assignee: David Lloyd Missing import in the module.xml for the tx client. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 21:52:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 22 Mar 2017 21:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1475) Convert project to use i18n logging and exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382673#comment-13382673 ] RH Bugzilla Integration commented on JGRP-1475: ----------------------------------------------- Brad Maxwell changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from POST to MODIFIED > Convert project to use i18n logging and exceptions > -------------------------------------------------- > > Key: JGRP-1475 > URL: https://issues.jboss.org/browse/JGRP-1475 > Project: JGroups > Issue Type: Task > Reporter: James Perkins > Assignee: Bela Ban > Priority: Minor > Fix For: 3.2 > > > As per [ANDIAMO-7|https://issues.jboss.org/browse/ANDIAMO-7] all messages (logged and exceptions) need a unique id. This need to be done using JBoss Logging, [ANDIAMO-2|https://issues.jboss.org/browse/ANDIAMO-2]. See [https://community.jboss.org/docs/DOC-18453] for information on configuring the loggers and message bundles. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 21:52:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 22 Mar 2017 21:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2060) Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382672#comment-13382672 ] RH Bugzilla Integration commented on JGRP-2060: ----------------------------------------------- Brad Maxwell changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from POST to MODIFIED > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2060 > URL: https://issues.jboss.org/browse/JGRP-2060 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Brad Maxwell > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 02:25:00 2017 From: issues at jboss.org (Jan Martiska (JIRA)) Date: Thu, 23 Mar 2017 02:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8424) Create test for @ClientInterceptors annotation of EJB client library In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Martiska moved JBEAP-9807 to WFLY-8424: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8424 (was: JBEAP-9807) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Test Suite (was: EJB) (was: Test Suite) > Create test for @ClientInterceptors annotation of EJB client library > -------------------------------------------------------------------- > > Key: WFLY-8424 > URL: https://issues.jboss.org/browse/WFLY-8424 > Project: WildFly > Issue Type: Task > Components: EJB, Test Suite > Reporter: Jan Martiska > Assignee: Jan Martiska > > example: > {noformat} > @ClientInterceptors({HelloClientInterceptor.class}) > public interface HelloBeanRemote { > public String hello(); > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 02:25:00 2017 From: issues at jboss.org (Jan Martiska (JIRA)) Date: Thu, 23 Mar 2017 02:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8424) Create test for @ClientInterceptors annotation from EJB client library In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Martiska updated WFLY-8424: ------------------------------- Summary: Create test for @ClientInterceptors annotation from EJB client library (was: Create test for @ClientInterceptors annotation of EJB client library) > Create test for @ClientInterceptors annotation from EJB client library > ---------------------------------------------------------------------- > > Key: WFLY-8424 > URL: https://issues.jboss.org/browse/WFLY-8424 > Project: WildFly > Issue Type: Task > Components: EJB, Test Suite > Reporter: Jan Martiska > Assignee: Jan Martiska > > example: > {noformat} > @ClientInterceptors({HelloClientInterceptor.class}) > public interface HelloBeanRemote { > public String hello(); > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 02:57:00 2017 From: issues at jboss.org (Jan Martiska (JIRA)) Date: Thu, 23 Mar 2017 02:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8425) Create test for setting invocation timeout for EJB client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Martiska moved JBEAP-9809 to WFLY-8425: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8425 (was: JBEAP-9809) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Test Suite (was: EJB) (was: Test Suite) > Create test for setting invocation timeout for EJB client > --------------------------------------------------------- > > Key: WFLY-8425 > URL: https://issues.jboss.org/browse/WFLY-8425 > Project: WildFly > Issue Type: Task > Components: EJB, Test Suite > Reporter: Jan Martiska > Assignee: Jan Martiska > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 03:57:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 23 Mar 2017 03:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8380) Xerces usage tests fail with security manager on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated WFLY-8380: ---------------------------- Summary: Xerces usage tests fail with security manager on IBM JDK (was: Xerces usage tests fail with security manager) > Xerces usage tests fail with security manager on IBM JDK > -------------------------------------------------------- > > Key: WFLY-8380 > URL: https://issues.jboss.org/browse/WFLY-8380 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}} > *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}} > {code} > 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) > at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) > at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) > at java.security.AccessController.doPrivileged(AccessController.java:620) > at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:346) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) > at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader") > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) > at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) > at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) > at java.security.AccessController.doPrivileged(AccessController.java:620) > at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:346) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) > at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 03:57:00 2017 From: issues at jboss.org (Jan Tymel (JIRA)) Date: Thu, 23 Mar 2017 03:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8380) Xerces usage tests fail with security manager on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tymel updated WFLY-8380: ---------------------------- Environment: IBM JDK > Xerces usage tests fail with security manager on IBM JDK > -------------------------------------------------------- > > Key: WFLY-8380 > URL: https://issues.jboss.org/browse/WFLY-8380 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Environment: IBM JDK > Reporter: Jan Tymel > > *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}} > *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}} > {code} > 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) > at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) > at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) > at java.security.AccessController.doPrivileged(AccessController.java:620) > at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:346) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) > at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader") > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar )" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" 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.SecurityManager.checkPackageAccess(SecurityManager.java:1655) > at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481) > at java.lang.J9VMInternals$2.run(J9VMInternals.java:259) > at java.security.AccessController.doPrivileged(AccessController.java:620) > at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257) > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:346) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) > at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123) > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402) > ... 25 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 04:20:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 23 Mar 2017 04:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8426) EJBClientDescriptorTestCase doesn't do a proper clean-up In-Reply-To: References: Message-ID: Josef Cacek created WFLY-8426: --------------------------------- Summary: EJBClientDescriptorTestCase doesn't do a proper clean-up Key: WFLY-8426 URL: https://issues.jboss.org/browse/WFLY-8426 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Josef Cacek The ServerSetupTask instance {{EJBClientDescriptorTestCase.EJBClientDescriptorTestCaseSetup}} has a wrong order of operations in {{tearDown}} method, so already the first operation fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 04:22:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 04:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7885) Persistent calendar timer force logging for each invocation if the deployed-class has changed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382729#comment-13382729 ] RH Bugzilla Integration commented on WFLY-7885: ----------------------------------------------- Petr Penicka changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from VERIFIED to CLOSED > Persistent calendar timer force logging for each invocation if the deployed-class has changed > --------------------------------------------------------------------------------------------- > > Key: WFLY-7885 > URL: https://issues.jboss.org/browse/WFLY-7885 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Ingo Weiss > Priority: Minor > Labels: ejb, ejb3.1, timers, timerservice > Fix For: 11.0.0.Alpha1 > > > It will be common to change classes which contains @Schedule timer methods. > In case such methods are removed or renamed (for persistent calendar timers) the server will log the following warning forever for each invocation. > WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=1a419372-d807-43d8-ac77-5be6696b022d) from its persistent state > As this is intentional there should be a WARN message at (first) deployment time and the timer should be removed from the persistence. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 04:22:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 04:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382730#comment-13382730 ] RH Bugzilla Integration commented on WFLY-4539: ----------------------------------------------- Petr Penicka changed the Status of [bug 1213316|https://bugzilla.redhat.com/show_bug.cgi?id=1213316] from VERIFIED to CLOSED > logging statement to trace remoting heartbeat > --------------------------------------------- > > Key: WFLY-4539 > URL: https://issues.jboss.org/browse/WFLY-4539 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Carsten Lichy-Bittendorf > Assignee: Peter Palaga > Priority: Minor > > you can set the heartbeat on a remoting connection by setting: > remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL > What is missing is the option to log on the client when the heartbeat message is fired. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:15:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 23 Mar 2017 05:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2396) credential-store and authentication-context in Elytron dir-context should be mutually exclusive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated WFCORE-2396: ------------------------------- Affects Version/s: 3.0.0.Beta9 > credential-store and authentication-context in Elytron dir-context should be mutually exclusive > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2396 > URL: https://issues.jboss.org/browse/WFCORE-2396 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > To avoid possibility when two different credentials are configured in Elytron dir-context, its attributes credential-store and authentication-context should be mutually exclusive. > This jira is based on discussion in JBEAP-8026. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:36:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 23 Mar 2017 05:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8426) EJBClientDescriptorTestCase doesn't do a proper clean-up In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek reassigned WFLY-8426: --------------------------------- Assignee: Josef Cacek > EJBClientDescriptorTestCase doesn't do a proper clean-up > -------------------------------------------------------- > > Key: WFLY-8426 > URL: https://issues.jboss.org/browse/WFLY-8426 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > The ServerSetupTask instance {{EJBClientDescriptorTestCase.EJBClientDescriptorTestCaseSetup}} has a wrong order of operations in {{tearDown}} method, so already the first operation fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:43:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 23 Mar 2017 05:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2163: --------------------------------- Priority: Blocker (was: Critical) > Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-2163 > URL: https://issues.jboss.org/browse/WFCORE-2163 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 3.0.0.Beta11 > > > In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started. > I am using following configuration for HTTP management interface (see Steps to Reproduce for more details): > {code} > > > > > {code} > Server is not started and following errors occur in log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > 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.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided. > at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225) > at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254) > at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107) > at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589) > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292) > ... 5 more > {code} > and > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {code} > According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication. > [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJiSEGwI/edit# -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:43:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 23 Mar 2017 05:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382784#comment-13382784 ] Ondrej Lukas commented on WFCORE-2163: -------------------------------------- Increasing priority to blocker since valid configuration causes that server does not start. > Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-2163 > URL: https://issues.jboss.org/browse/WFCORE-2163 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 3.0.0.Beta11 > > > In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started. > I am using following configuration for HTTP management interface (see Steps to Reproduce for more details): > {code} > > > > > {code} > Server is not started and following errors occur in log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > 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.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided. > at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225) > at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254) > at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107) > at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589) > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292) > ... 5 more > {code} > and > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {code} > According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication. > [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJiSEGwI/edit# -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:43:01 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 05:43:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7834) A test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412] In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382785#comment-13382785 ] RH Bugzilla Integration commented on WFLY-7834: ----------------------------------------------- Petr Penicka changed the Status of [bug 1280512|https://bugzilla.redhat.com/show_bug.cgi?id=1280512] from VERIFIED to CLOSED > A test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412] > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7834 > URL: https://issues.jboss.org/browse/WFLY-7834 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 11.0.0.Alpha1 > > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Add an integration test that will prove that SECURITY-930 and WFLY-7412 were properly fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:43:01 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 05:43:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382786#comment-13382786 ] RH Bugzilla Integration commented on SECURITY-930: -------------------------------------------------- Petr Penicka changed the Status of [bug 1280512|https://bugzilla.redhat.com/show_bug.cgi?id=1280512] from VERIFIED to CLOSED > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: SECURITY-930 > URL: https://issues.jboss.org/browse/SECURITY-930 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Reporter: Derek Horton > Assignee: Stefan Guilhen > Fix For: PicketBox_5_0_0.Beta1 > > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > > > > > > > > > > > > > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. > There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 05:49:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 23 Mar 2017 05:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2565) Incorrect permission class-name should throw exception at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2565: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Incorrect permission class-name should throw exception at runtime > ----------------------------------------------------------------- > > Key: WFCORE-2565 > URL: https://issues.jboss.org/browse/WFCORE-2565 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > > In case when some permission mapper (tried with constant-permission-mapper and simple-permission-mapper) includes permission with non-existent class-name then it seems that no exception is thrown during runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 06:11:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Thu, 23 Mar 2017 06:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1492) typeRef allowed values check for DT input and output clauses, and InputData In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Mortari updated DROOLS-1492: ----------------------------------- Summary: typeRef allowed values check for DT input and output clauses, and InputData (was: DecisionTable to perform typeRef allowed values check for input and output clause) > typeRef allowed values check for DT input and output clauses, and InputData > --------------------------------------------------------------------------- > > Key: DROOLS-1492 > URL: https://issues.jboss.org/browse/DROOLS-1492 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Example model > {code:xml} > > feel:string > > "a","b","c" > > > > > > > > > > > > > > MyInput > > > > > > - > > > "Decision taken" > > > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 07:39:01 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 07:39:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2157) Full-replace rollback is failing with java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child > 'name' exists In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382886#comment-13382886 ] RH Bugzilla Integration commented on WFCORE-2157: ------------------------------------------------- Petr Penicka changed the Status of [bug 1409644|https://bugzilla.redhat.com/show_bug.cgi?id=1409644] from VERIFIED to CLOSED > Full-replace rollback is failing with java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child > 'name' exists > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2157 > URL: https://issues.jboss.org/browse/WFCORE-2157 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Labels: downstream_dependency > Fix For: 3.0.0.Alpha18 > > > 21:24:18,013 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 56) WFLYCTL0190: Step > > handler org.jboss.as.server.deployment.DeploymentHandlerUtil$4 at 6f678cd for operation {"operation" => "full-replace-deployment","name" => > > "drmk22.ear","enabled" => true,"content" => [{"hash" => bytes { 0x40, 0xde, 0xe4, 0x1d, 0xdd, 0xd0, 0xa7, 0x9f, 0xa9, 0x7a, 0x92, 0x84, > > 0xee, 0x92, 0x81, 0xea, 0x5d, 0x7b, 0xa3, 0x2a }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => > > "cf11aeb2-70b8-4f64-aa64-67fffd9c8080"},"address" => [],"runtime-name" => undefined,"persistent" => true,"owner" => undefined} at address [] > > failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child > > 'name' exists > > at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:387) > > at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:302) > > at org.jboss.dmr.ModelNode.require(ModelNode.java:875) > > at org.jboss.as.server.deployment.DeploymentHandlerUtil$4$1.handleResult(DeploymentHandlerUtil.java:331) > > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1435) > > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1417) > > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1379) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 07:39:01 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 07:39:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1047) Rollback of undeploy and deployment remove will fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382887#comment-13382887 ] RH Bugzilla Integration commented on WFCORE-1047: ------------------------------------------------- Petr Penicka changed the Status of [bug 1409644|https://bugzilla.redhat.com/show_bug.cgi?id=1409644] from VERIFIED to CLOSED > Rollback of undeploy and deployment remove will fail > ---------------------------------------------------- > > Key: WFCORE-1047 > URL: https://issues.jboss.org/browse/WFCORE-1047 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Final, 2.0.0.CR6 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 2.0.0.CR7 > > > This looks like a problem that's been around since Sept 2012. > The rollback handling in DeploymentHandlerUtil.undeploy and in DeploymentRemoveHandler both try to read the deployment's management name from the deployment resource, but since [1] it hasn't been stored there. So rollback will fail with something like this: > {code} > [Server:main-one] 15:58:54,894 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 2) WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$5 at 2a0a9f3f for operation {"operation" => "undeploy","address" => [("deployment" => "broken.jar")],"operation-headers" => {}} at address [("deployment" => "broken.jar")] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists > [Server:main-one] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final] > [Server:main-one] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final] > [Server:main-one] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final] > [Server:main-one] at org.jboss.as.server.deployment.DeploymentHandlerUtil$5$1.handleResult(DeploymentHandlerUtil.java:331) [wildfly-server-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45] > [Server:main-one] at javax.security.auth.Subject.doAs(Subject.java:360) [rt.jar:1.8.0_45] > [Server:main-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45] > [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:466) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT] > [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > [Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > [Server:main-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] > {code} > [1] https://github.com/wildfly/wildfly-core/commit/f38b37#diff-2dbd1fc9261de7a938948b642aa8d47dL153 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 08:18:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Thu, 23 Mar 2017 08:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-75) Fix Jenkins Solenium CF-UI Suite Hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney resolved HAWKULARQE-75. ------------------------------------ Resolution: Done > Fix Jenkins Solenium CF-UI Suite Hang > ------------------------------------- > > Key: HAWKULARQE-75 > URL: https://issues.jboss.org/browse/HAWKULARQE-75 > Project: Hawkular QE > Issue Type: Task > Environment: CF-UI suite hangs when running on Jenkins Selenium Server. > Ref task: https://issues.jboss.org/browse/HAWKULARQE-45 > Reporter: Matt Mahoney > Assignee: Matt Mahoney > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 08:44:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Thu, 23 Mar 2017 08:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8427) Unignore XADatasourceCapacityPoliciesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan moved JBEAP-9841 to WFLY-8427: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8427 (was: JBEAP-9841) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Unignore XADatasourceCapacityPoliciesTestCase > --------------------------------------------- > > Key: WFLY-8427 > URL: https://issues.jboss.org/browse/WFLY-8427 > Project: WildFly > Issue Type: Bug > Reporter: Kabir Khan > Assignee: Stefano Maestri > > I am going to ignore this test, until the ironjacamar upgrade which fixes the following (from [~simkam]'s mail) > {quote} > I might be completely wrong, but it seems to me like race condition between PoolFiller and CapacityFiller in IronJacamar. > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163 > @Stefano, @Flavia could you please take a look? > I'm attaching logs with enabled TRACE on org.jboss.jca and jdbc.spy. > This might have been hidden until https://issues.jboss.org/browse/JBJCA-1330 was fixed in DR11. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 08:53:00 2017 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Thu, 23 Mar 2017 08:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8427) Unignore XADatasourceCapacityPoliciesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri reassigned WFLY-8427: ------------------------------------- Assignee: Flavia Rainone (was: Stefano Maestri) > Unignore XADatasourceCapacityPoliciesTestCase > --------------------------------------------- > > Key: WFLY-8427 > URL: https://issues.jboss.org/browse/WFLY-8427 > Project: WildFly > Issue Type: Bug > Reporter: Kabir Khan > Assignee: Flavia Rainone > > I am going to ignore this test, until the ironjacamar upgrade which fixes the following (from [~simkam]'s mail) > {quote} > I might be completely wrong, but it seems to me like race condition between PoolFiller and CapacityFiller in IronJacamar. > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/org/jboss/jca/core/connectionmanager/pool/mcp/SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163 > @Stefano, @Flavia could you please take a look? > I'm attaching logs with enabled TRACE on org.jboss.jca and jdbc.spy. > This might have been hidden until https://issues.jboss.org/browse/JBJCA-1330 was fixed in DR11. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:10:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 23 Mar 2017 09:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* In-Reply-To: References: Message-ID: Harald Pehl created WFLY-8428: --------------------------------- Summary: :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* Key: WFLY-8428 URL: https://issues.jboss.org/browse/WFLY-8428 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Harald Pehl Assignee: Stuart Douglas {{:read-resource(include-runtime=true)}} is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: {code} [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) { "outcome" => "failed", "rolled-back" => true } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:10:01 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 23 Mar 2017 09:10:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-8428: ------------------------------ Description: The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: {code} [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) { "outcome" => "failed", "rolled-back" => true } {code} was: {{:read-resource(include-runtime=true)}} is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: {code} [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) { "outcome" => "failed", "rolled-back" => true } {code} > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Stuart Douglas > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:12:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 23 Mar 2017 09:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382982#comment-13382982 ] Brian Stansberry commented on WFLY-8428: ---------------------------------------- Is there anything in the server.log? > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Stuart Douglas > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:38:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 09:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382997#comment-13382997 ] Carlo de Wolf commented on JBMETA-399: -------------------------------------- Using Maven 3.3.9 directly the issue does not appear, so I reckon it is an issue with the way either Guice or Maven is packaged on Ubuntu. {code} $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" {code} > Metadata doesn't compile with Java 9 EA > --------------------------------------- > > Key: JBMETA-399 > URL: https://issues.jboss.org/browse/JBMETA-399 > Project: JBoss Metadata > Issue Type: Task > Reporter: Carlo de Wolf > > {code} > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Results in: > {code} > $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package > --------------------------------------------------- > constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar > constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar > constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar > constituent[3]: file:/usr/share/maven/lib/cdi-api.jar > constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar > constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar > constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar > constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar > constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar > constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar > constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar > constituent[11]: file:/usr/share/maven/lib/javax.inject.jar > constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar > constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar > constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar > constituent[15]: file:/usr/share/maven/lib/guava.jar > constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar > constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar > constituent[18]: file:/usr/share/maven/lib/commons-lang.jar > constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar > constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar > constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar > constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar > constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar > constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar > constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar > constituent[26]: file:/usr/share/maven/lib/commons-io.jar > constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar > constituent[28]: file:/usr/share/maven/lib/commons-cli.jar > constituent[29]: file:/usr/share/maven/lib/wagon-file.jar > constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar > constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar > constituent[32]: file:/usr/share/maven/lib/aopalliance.jar > constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar > constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar > constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar > constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar > constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar > constituent[38]: file:/usr/share/maven/lib/guice.jar > constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar > constituent[40]: file:/usr/share/maven/lib/jsoup.jar > constituent[41]: file:/usr/share/maven/conf/logging/ > --------------------------------------------------- > Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) > at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) > at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) > at com.google.inject.internal.FailableCache.get(FailableCache.java:48) > at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) > at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) > at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) > at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) > at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) > at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) > at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) > at com.google.inject.Guice.createInjector(Guice.java:99) > at com.google.inject.Guice.createInjector(Guice.java:73) > at com.google.inject.Guice.createInjector(Guice.java:62) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) > at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:39:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 09:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf updated JBMETA-399: --------------------------------- Environment: $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 9-ea, vendor: Oracle Corporation Java home: /opt/oracle/jdk-9-ea+161 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > Metadata doesn't compile with Java 9 EA > --------------------------------------- > > Key: JBMETA-399 > URL: https://issues.jboss.org/browse/JBMETA-399 > Project: JBoss Metadata > Issue Type: Task > Environment: $ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 > DISTRIB_CODENAME=xenial > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > Reporter: Carlo de Wolf > > {code} > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Results in: > {code} > $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package > --------------------------------------------------- > constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar > constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar > constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar > constituent[3]: file:/usr/share/maven/lib/cdi-api.jar > constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar > constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar > constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar > constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar > constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar > constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar > constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar > constituent[11]: file:/usr/share/maven/lib/javax.inject.jar > constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar > constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar > constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar > constituent[15]: file:/usr/share/maven/lib/guava.jar > constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar > constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar > constituent[18]: file:/usr/share/maven/lib/commons-lang.jar > constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar > constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar > constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar > constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar > constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar > constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar > constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar > constituent[26]: file:/usr/share/maven/lib/commons-io.jar > constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar > constituent[28]: file:/usr/share/maven/lib/commons-cli.jar > constituent[29]: file:/usr/share/maven/lib/wagon-file.jar > constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar > constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar > constituent[32]: file:/usr/share/maven/lib/aopalliance.jar > constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar > constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar > constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar > constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar > constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar > constituent[38]: file:/usr/share/maven/lib/guice.jar > constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar > constituent[40]: file:/usr/share/maven/lib/jsoup.jar > constituent[41]: file:/usr/share/maven/conf/logging/ > --------------------------------------------------- > Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) > at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) > at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) > at com.google.inject.internal.FailableCache.get(FailableCache.java:48) > at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) > at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) > at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) > at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) > at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) > at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) > at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) > at com.google.inject.Guice.createInjector(Guice.java:99) > at com.google.inject.Guice.createInjector(Guice.java:73) > at com.google.inject.Guice.createInjector(Guice.java:62) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) > at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:39:01 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Thu, 23 Mar 2017 09:39:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8429) Pooled connection factory with default discovery group is not able to connect to cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil moved JBEAP-9843 to WFLY-8429: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8429 (was: JBEAP-9843) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: (was: 7.1.0.DR14) > Pooled connection factory with default discovery group is not able to connect to cluster > ---------------------------------------------------------------------------------------- > > Key: WFLY-8429 > URL: https://issues.jboss.org/browse/WFLY-8429 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Test Scenario: > * Start 1st EAP 7.1 server with deployed queues InQueue and OutQueue > * Start 2nd EAP 7.1 server with MDB which consumes messages from InQueue and resends to OutQueue > ** pooled-connection-factory is using default {{discovery-group="dg-group1"}} to get connectors to 1st EAP 7.1 server > * Send messages to InQueue and consume from OutQueue > Pass Criteria: Number of send and received messages is the same. > Actual Result: > MDB does not start to consume messages from InQueue. > Expected Result: > MDB will resend messages from InQueue to OutQueue. > Attaching configuration and trace logs from test. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:45:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 23 Mar 2017 09:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383008#comment-13383008 ] Harald Pehl commented on WFLY-8428: ----------------------------------- Yes, seems related to the capabilities: {code} 14:42:48,163 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([ ("subsystem" => "undertow"), ("application-security-domain" => "foo") ]): java.lang.IllegalArgumentException: WFLYCTL0394: Capability 'org.wildfly.extension.undertow.application-security-domain.foo' does not provide services of type 'interface java.util.function.Function' at org.jboss.as.controller.capability.RuntimeCapability.getCapabilityServiceName(RuntimeCapability.java:183) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ReferencingDeploymentsHandler.execute(ApplicationSecurityDomainDefinition.java:237) at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174) at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137) at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231) at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:989) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Stuart Douglas > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:46:01 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 23 Mar 2017 09:46:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8430) EJB call through remote-outbound-connection doesn't authenticate with Elytron In-Reply-To: References: Message-ID: Josef Cacek created WFLY-8430: --------------------------------- Summary: EJB call through remote-outbound-connection doesn't authenticate with Elytron Key: WFLY-8430 URL: https://issues.jboss.org/browse/WFLY-8430 Project: WildFly Issue Type: Bug Components: EJB, Security Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Critical The {{remote-outbound-connection}} with user authentication configured, doesn't work with Elytron because the SASL authentication fails. Scenario: * from a deployment is made a remote EJB call through defined remote-outbound-connection (which specifies valid username and legacy security realm with valid password) Current behavior: * The call fails with authentication exception (for Elytron configuration). Expected behavior: * The remote EJB call is allowed with Elytron configured as the default security provider -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 09:50:02 2017 From: issues at jboss.org (Dimitris Andreadis (JIRA)) Date: Thu, 23 Mar 2017 09:50:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2532) Some logging tests fail with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dimitris Andreadis reassigned WFCORE-2532: ------------------------------------------ Assignee: James Perkins > Some logging tests fail with security manager in WF core > -------------------------------------------------------- > > Key: WFCORE-2532 > URL: https://issues.jboss.org/browse/WFCORE-2532 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > > * *org.jboss.as.test.integration.logging.operations.CustomFormattersTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerOperationsTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.operations.Log4jCustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLog4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.LoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase* > * *org.jboss.as.test.integration.logging.profiles.NonExistingProfileTestCase* > * *org.jboss.as.test.integration.logging.syslog.SyslogHandlerTestCase* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=org.jboss.as.test.integration.logging.**.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging1.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging1.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging1.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging1.jar )\" of \"ModuleClassLoader for Module \"deployment.logging1.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging1.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.test.integration.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:168) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:314) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:304) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.testProfiles(LoggingProfilesTestCase.java:201 > {code} > * *org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase* > * *org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase* > * *org.jboss.as.test.manualmode.logging.PerDeployLoggingTestCase* > * *org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase* > * *org.jboss.as.test.manualmode.logging.SizeAppenderRestartTestCase* > * *org.jboss.as.test.manualmode.logging.SyslogIsNotAvailableDuringServerBootTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -Dtest=org.jboss.as.test.manualmode.logging.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging-test.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging-test.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging-test.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging-test.jar )\" of \"ModuleClassLoader for Module \"deployment.logging-test.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging-test.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.wildfly.core.testrunner.ServerController.deploy(ServerController.java:92) > at org.jboss.as.test.manualmode.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:197) > at org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase.startContainer(Log4jAppenderTestCase.java:93) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:10:02 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 10:10:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBJCA-1338: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1195079 Bugzilla Update: Perform > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1338 > URL: https://issues.jboss.org/browse/JBJCA-1338 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.2.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:16:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 10:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf updated JBMETA-399: --------------------------------- Environment: {{$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 9-ea, vendor: Oracle Corporation Java home: /opt/oracle/jdk-9-ea+161 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix"}} was: $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 9-ea, vendor: Oracle Corporation Java home: /opt/oracle/jdk-9-ea+161 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > Metadata doesn't compile with Java 9 EA > --------------------------------------- > > Key: JBMETA-399 > URL: https://issues.jboss.org/browse/JBMETA-399 > Project: JBoss Metadata > Issue Type: Task > Environment: {{$ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 > DISTRIB_CODENAME=xenial > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix"}} > Reporter: Carlo de Wolf > > {code} > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Results in: > {code} > $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package > --------------------------------------------------- > constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar > constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar > constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar > constituent[3]: file:/usr/share/maven/lib/cdi-api.jar > constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar > constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar > constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar > constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar > constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar > constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar > constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar > constituent[11]: file:/usr/share/maven/lib/javax.inject.jar > constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar > constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar > constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar > constituent[15]: file:/usr/share/maven/lib/guava.jar > constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar > constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar > constituent[18]: file:/usr/share/maven/lib/commons-lang.jar > constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar > constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar > constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar > constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar > constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar > constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar > constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar > constituent[26]: file:/usr/share/maven/lib/commons-io.jar > constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar > constituent[28]: file:/usr/share/maven/lib/commons-cli.jar > constituent[29]: file:/usr/share/maven/lib/wagon-file.jar > constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar > constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar > constituent[32]: file:/usr/share/maven/lib/aopalliance.jar > constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar > constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar > constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar > constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar > constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar > constituent[38]: file:/usr/share/maven/lib/guice.jar > constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar > constituent[40]: file:/usr/share/maven/lib/jsoup.jar > constituent[41]: file:/usr/share/maven/conf/logging/ > --------------------------------------------------- > Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) > at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) > at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) > at com.google.inject.internal.FailableCache.get(FailableCache.java:48) > at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) > at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) > at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) > at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) > at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) > at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) > at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) > at com.google.inject.Guice.createInjector(Guice.java:99) > at com.google.inject.Guice.createInjector(Guice.java:73) > at com.google.inject.Guice.createInjector(Guice.java:62) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) > at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:17:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 10:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf updated JBMETA-399: --------------------------------- Environment: {code} $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 9-ea, vendor: Oracle Corporation Java home: /opt/oracle/jdk-9-ea+161 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" {code} was: {{$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 9-ea, vendor: Oracle Corporation Java home: /opt/oracle/jdk-9-ea+161 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix"}} > Metadata doesn't compile with Java 9 EA > --------------------------------------- > > Key: JBMETA-399 > URL: https://issues.jboss.org/browse/JBMETA-399 > Project: JBoss Metadata > Issue Type: Task > Environment: {code} > $ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 > DISTRIB_CODENAME=xenial > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Reporter: Carlo de Wolf > > {code} > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Results in: > {code} > $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package > --------------------------------------------------- > constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar > constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar > constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar > constituent[3]: file:/usr/share/maven/lib/cdi-api.jar > constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar > constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar > constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar > constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar > constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar > constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar > constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar > constituent[11]: file:/usr/share/maven/lib/javax.inject.jar > constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar > constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar > constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar > constituent[15]: file:/usr/share/maven/lib/guava.jar > constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar > constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar > constituent[18]: file:/usr/share/maven/lib/commons-lang.jar > constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar > constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar > constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar > constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar > constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar > constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar > constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar > constituent[26]: file:/usr/share/maven/lib/commons-io.jar > constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar > constituent[28]: file:/usr/share/maven/lib/commons-cli.jar > constituent[29]: file:/usr/share/maven/lib/wagon-file.jar > constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar > constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar > constituent[32]: file:/usr/share/maven/lib/aopalliance.jar > constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar > constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar > constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar > constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar > constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar > constituent[38]: file:/usr/share/maven/lib/guice.jar > constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar > constituent[40]: file:/usr/share/maven/lib/jsoup.jar > constituent[41]: file:/usr/share/maven/conf/logging/ > --------------------------------------------------- > Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) > at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) > at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) > at com.google.inject.internal.FailableCache.get(FailableCache.java:48) > at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) > at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) > at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) > at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) > at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) > at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) > at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) > at com.google.inject.Guice.createInjector(Guice.java:99) > at com.google.inject.Guice.createInjector(Guice.java:73) > at com.google.inject.Guice.createInjector(Guice.java:62) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) > at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:17:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 10:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf reassigned JBMETA-399: ------------------------------------ Assignee: Carlo de Wolf > Metadata doesn't compile with Java 9 EA > --------------------------------------- > > Key: JBMETA-399 > URL: https://issues.jboss.org/browse/JBMETA-399 > Project: JBoss Metadata > Issue Type: Task > Environment: {code} > $ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 > DISTRIB_CODENAME=xenial > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > > {code} > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Results in: > {code} > $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package > --------------------------------------------------- > constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar > constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar > constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar > constituent[3]: file:/usr/share/maven/lib/cdi-api.jar > constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar > constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar > constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar > constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar > constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar > constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar > constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar > constituent[11]: file:/usr/share/maven/lib/javax.inject.jar > constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar > constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar > constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar > constituent[15]: file:/usr/share/maven/lib/guava.jar > constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar > constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar > constituent[18]: file:/usr/share/maven/lib/commons-lang.jar > constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar > constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar > constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar > constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar > constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar > constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar > constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar > constituent[26]: file:/usr/share/maven/lib/commons-io.jar > constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar > constituent[28]: file:/usr/share/maven/lib/commons-cli.jar > constituent[29]: file:/usr/share/maven/lib/wagon-file.jar > constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar > constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar > constituent[32]: file:/usr/share/maven/lib/aopalliance.jar > constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar > constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar > constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar > constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar > constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar > constituent[38]: file:/usr/share/maven/lib/guice.jar > constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar > constituent[40]: file:/usr/share/maven/lib/jsoup.jar > constituent[41]: file:/usr/share/maven/conf/logging/ > --------------------------------------------------- > Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) > at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) > at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) > at com.google.inject.internal.FailableCache.get(FailableCache.java:48) > at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) > at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) > at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) > at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) > at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) > at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) > at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) > at com.google.inject.Guice.createInjector(Guice.java:99) > at com.google.inject.Guice.createInjector(Guice.java:73) > at com.google.inject.Guice.createInjector(Guice.java:62) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) > at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:17:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 10:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf resolved JBMETA-399. ---------------------------------- Resolution: Rejected > Metadata doesn't compile with Java 9 EA > --------------------------------------- > > Key: JBMETA-399 > URL: https://issues.jboss.org/browse/JBMETA-399 > Project: JBoss Metadata > Issue Type: Task > Environment: {code} > $ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 > DISTRIB_CODENAME=xenial > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > > {code} > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 9-ea, vendor: Oracle Corporation > Java home: /opt/oracle/jdk-9-ea+161 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix" > {code} > Results in: > {code} > $ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package > --------------------------------------------------- > constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar > constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar > constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar > constituent[3]: file:/usr/share/maven/lib/cdi-api.jar > constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar > constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar > constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar > constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar > constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar > constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar > constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar > constituent[11]: file:/usr/share/maven/lib/javax.inject.jar > constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar > constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar > constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar > constituent[15]: file:/usr/share/maven/lib/guava.jar > constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar > constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar > constituent[18]: file:/usr/share/maven/lib/commons-lang.jar > constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar > constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar > constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar > constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar > constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar > constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar > constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar > constituent[26]: file:/usr/share/maven/lib/commons-io.jar > constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar > constituent[28]: file:/usr/share/maven/lib/commons-cli.jar > constituent[29]: file:/usr/share/maven/lib/wagon-file.jar > constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar > constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar > constituent[32]: file:/usr/share/maven/lib/aopalliance.jar > constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar > constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar > constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar > constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar > constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar > constituent[38]: file:/usr/share/maven/lib/guice.jar > constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar > constituent[40]: file:/usr/share/maven/lib/jsoup.jar > constituent[41]: file:/usr/share/maven/conf/logging/ > --------------------------------------------------- > Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955) > at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870) > at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876) > at com.google.inject.internal.FailableCache.get(FailableCache.java:48) > at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50) > at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137) > at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533) > at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160) > at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44) > at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123) > at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) > at com.google.inject.Guice.createInjector(Guice.java:99) > at com.google.inject.Guice.createInjector(Guice.java:73) > at com.google.inject.Guice.createInjector(Guice.java:62) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206) > at org.apache.maven.cli.MavenCli.container(MavenCli.java:545) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73) > at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206) > at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65) > at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204) > at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55) > at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159) > at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90) > at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37) > at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33) > at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37) > at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321) > at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:25:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Thu, 23 Mar 2017 10:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: Istv?n T?th created WFLY-8431: --------------------------------- Summary: Race conditions in JASPIC registration code Key: WFLY-8431 URL: https://issues.jboss.org/browse/WFLY-8431 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 10.1.0.Final Environment: Centos 7 x86_64, with the included Java 8 environment Reporter: Istv?n T?th Assignee: Darran Lofthouse javax.security.auth.message.config.AuthConfigFactory and org.jboss.security.auth.message.config.JBossAuthConfigFactory have race conditions. 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. Nearly all methods of this class manipulate these, without any synchronization. In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. The methods that modify the maps should also be made synchronized, or rewritten to use the atomic ConcurrentHashMaps operations. A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:28:00 2017 From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=) Date: Thu, 23 Mar 2017 10:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8432) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: J?rg B?sner created WFLY-8432: --------------------------------- Summary: Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8432 URL: https://issues.jboss.org/browse/WFLY-8432 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: J?rg B?sner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:31:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 23 Mar 2017 10:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-70) Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383058#comment-13383058 ] Sunil kondkar commented on HAWKULARQE-70: ----------------------------------------- Closing ticket as PR is merged > Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server > --------------------------------------------------------------------------------- > > Key: HAWKULARQE-70 > URL: https://issues.jboss.org/browse/HAWKULARQE-70 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Need of the task: > To make sure the CFME docker instance that we use on Jenkins nightly run has CFME containers always running, we use docker scripts. > These are existing shell scripts which are using old methods to create cfme docker container and then start the cfme instance which are irrelevant now: > These are located at: > https://github.com/Hawkular-QE/cf-ui/tree/master/scripts/automation/docker > This task is to: > 1) Modify the scripts (common.sh, start.sh) to: > -Stop the CFME instance > -Start the CFME instance > -Check if the URL is ready using curl > -Check the logs if CFME is started > 2) Git clone the modified scripts to CFME server > 3) Execute the scripts on CFME server > ( Use 'execute shell script' on Jenkins nightly job to ssh/git clone and execute script on CFME server) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:31:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Thu, 23 Mar 2017 10:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8432) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383060#comment-13383060 ] Jeff Mesnil commented on WFLY-8432: ----------------------------------- This causes issue when WildFly is behind a load balancer as the JMS client would use the host of the http-socket binding (localhost) instead going through the loadbalancer. If the config is: {code} {code} The http-connector transport configuration should use 192.168.122.199 and 8000 as host and port (instead of localhost and 8080). > Support socket-binding attribute "client-mapping" in messaging subsystem > ------------------------------------------------------------------------ > > Key: WFLY-8432 > URL: https://issues.jboss.org/browse/WFLY-8432 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: J?rg B?sner > Assignee: Jeff Mesnil > > The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:31:01 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Thu, 23 Mar 2017 10:31:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8432) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383060#comment-13383060 ] Jeff Mesnil edited comment on WFLY-8432 at 3/23/17 10:30 AM: ------------------------------------------------------------- This causes issue when WildFly is behind a load balancer as the JMS client would use the host of the http-socket binding (localhost) instead going through the loadbalancer. If the config is: {code} {code} The http-connector transport configuration should use 192.168.122.199 and 8000 as host and port (instead of localhost and 8080). was (Author: jmesnil): This causes issue when WildFly is behind a load balancer as the JMS client would use the host of the http-socket binding (localhost) instead going through the loadbalancer. If the config is: {code} {code} The http-connector transport configuration should use 192.168.122.199 and 8000 as host and port (instead of localhost and 8080). > Support socket-binding attribute "client-mapping" in messaging subsystem > ------------------------------------------------------------------------ > > Key: WFLY-8432 > URL: https://issues.jboss.org/browse/WFLY-8432 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: J?rg B?sner > Assignee: Jeff Mesnil > > The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:31:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 23 Mar 2017 10:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-70) Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar resolved HAWKULARQE-70. ------------------------------------- Resolution: Done > Refactor existing CF-UI shell scripts for starting/stopping CFME on docker server > --------------------------------------------------------------------------------- > > Key: HAWKULARQE-70 > URL: https://issues.jboss.org/browse/HAWKULARQE-70 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Need of the task: > To make sure the CFME docker instance that we use on Jenkins nightly run has CFME containers always running, we use docker scripts. > These are existing shell scripts which are using old methods to create cfme docker container and then start the cfme instance which are irrelevant now: > These are located at: > https://github.com/Hawkular-QE/cf-ui/tree/master/scripts/automation/docker > This task is to: > 1) Modify the scripts (common.sh, start.sh) to: > -Stop the CFME instance > -Start the CFME instance > -Check if the URL is ready using curl > -Check the logs if CFME is started > 2) Git clone the modified scripts to CFME server > 3) Execute the scripts on CFME server > ( Use 'execute shell script' on Jenkins nightly job to ssh/git clone and execute script on CFME server) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:39:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 23 Mar 2017 10:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-79) Test Classic search/Advanced search on middleware pages In-Reply-To: References: Message-ID: Sunil kondkar created HAWKULARQE-79: --------------------------------------- Summary: Test Classic search/Advanced search on middleware pages Key: HAWKULARQE-79 URL: https://issues.jboss.org/browse/HAWKULARQE-79 Project: Hawkular QE Issue Type: Task Reporter: Sunil kondkar Assignee: Michael Foley Task to test classic/advanced search options on middleware pages except on topology page. Reference Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1403213 Tasks: * Review existing search test cases * Add any missing test cases * Execute test cases on CFME 5.8.0.7 * Report any bugs -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:39:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 23 Mar 2017 10:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-79) Test Classic search/Advanced search on middleware pages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar reassigned HAWKULARQE-79: --------------------------------------- Assignee: Sunil kondkar (was: Michael Foley) > Test Classic search/Advanced search on middleware pages > ------------------------------------------------------- > > Key: HAWKULARQE-79 > URL: https://issues.jboss.org/browse/HAWKULARQE-79 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to test classic/advanced search options on middleware pages except on topology page. > Reference Bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1403213 > Tasks: > * Review existing search test cases > * Add any missing test cases > * Execute test cases on CFME 5.8.0.7 > * Report any bugs -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:39:01 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Thu, 23 Mar 2017 10:39:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383063#comment-13383063 ] Istv?n T?th commented on WFLY-8431: ----------------------------------- Further analysis: In the above example the following code snippet registers the AuthConfiProvider: {{ logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId; }} It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: {{ 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " }} The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : {{ 2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " }} This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:40:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Thu, 23 Mar 2017 10:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383063#comment-13383063 ] Istv?n T?th edited comment on WFLY-8431 at 3/23/17 10:39 AM: ------------------------------------------------------------- Further analysis: In the above example the following code snippet registers the AuthConfiProvider: {{logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId;}} It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: {{2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu "}} The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : {{2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu "}} This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. was (Author: stoty2): Further analysis: In the above example the following code snippet registers the AuthConfiProvider: {{ logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId; }} It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: {{ 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " }} The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : {{ 2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " }} This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:41:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Thu, 23 Mar 2017 10:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383063#comment-13383063 ] Istv?n T?th edited comment on WFLY-8431 at 3/23/17 10:40 AM: ------------------------------------------------------------- Further analysis: In the above example the following code snippet registers the AuthConfiProvider: logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId; It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : 2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. was (Author: stoty2): Further analysis: In the above example the following code snippet registers the AuthConfiProvider: {{logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId;}} It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: {{2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu "}} The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : {{2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu "}} This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:42:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Thu, 23 Mar 2017 10:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383063#comment-13383063 ] Istv?n T?th edited comment on WFLY-8431 at 3/23/17 10:41 AM: ------------------------------------------------------------- Further analysis: In the above example the following code snippet registers the AuthConfiProvider: logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId; It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: ----------------------------------------------------------------------------------------------------- 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " ------------------------------------------------------------------------------------------------------------ The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : --------------------------------------------------------------------------------------------------------------- 2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " ----------------------------------------------------------------------------------------------------------------- This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. was (Author: stoty2): Further analysis: In the above example the following code snippet registers the AuthConfiProvider: logger.info("about to register JASPI SAM."); AuthConfigFactory acf = AuthConfigFactory.getFactory(); logger.info("AuthConfigFactory acf:" + acf); String providerId = acf.registerConfigProvider(new NFAuthConfigProvider(), "HttpServlet", getAppContextID(context), "Netfone CRM authentication config provider"); logger.info("registered JASPI SAM: \"" + providerId +"\""); return providerId; It is used and called from a @Weblistener contextInitialized() on six deployments. The relevant log looks like this: 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) about to register JASPI SAM. 2017-03-23 15:16:53,467 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:16:53,468 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) about to register JASPI SAM. 2017-03-23 15:16:53,469 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) about to register JASPI SAM. 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 70750ec0 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7178b09 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 7bb46782 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 73a9841c 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 70) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,470 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 61) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 75) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory@ 65438534 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 69) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:16:53,471 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 72) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " The takeaway is this: The contextInitialized() calls are called at the same time by WF. The AuthConfigFactory.getFactory() method returns different instances for the different threads because of the first race condition. The log output from wildfly startup, when the above code snippet is enclosed in a synchronized(AuthConfigFactory.class) block {} : 2017-03-23 15:15:22,044 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) about to register JASPI SAM. 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,047 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 104) registered JASPI SAM: "HttpServletnftccrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,047 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 77) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,051 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,055 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 58) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,058 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 66) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) about to register JASPI SAM. 2017-03-23 15:15:22,061 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,062 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 68) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,062 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 58) registered JASPI SAM: "HttpServletnfcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 66) registered JASPI SAM: "HttpServletnfugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) about to register JASPI SAM. 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,063 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 77) registered JASPI SAM: "HttpServletmhugyfelkaputeszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 58) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,066 INFO [se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor] (ServerService Thread Pool -- 103) Initializing by loading some known offenders with leak safe classloader 2017-03-23 15:15:22,067 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 77) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '' 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) about to register JASPI SAM. 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) AuthConfigFactory acf:org.jboss.security.auth.message.config.JBossAuthConfigFactory at 7a0df6e8 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 103) registered JASPI SAM: "HttpServletmhcrmteszt.sekhmet.netfone.hu " 2017-03-23 15:15:22,070 INFO [hu.netfone.security.jaspi.JaspicUtils] (ServerService Thread Pool -- 68) registered JASPI SAM: "HttpServletnftcugyfelkaputeszt.sekhmet.netfone.hu " This time the same AuthConfigFactory object is returned to all callers, and JASPIC authentication works. > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:44:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 23 Mar 2017 10:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-80) Refactor cf-ui datasource tests for changed datasource UI In-Reply-To: References: Message-ID: Sunil kondkar created HAWKULARQE-80: --------------------------------------- Summary: Refactor cf-ui datasource tests for changed datasource UI Key: HAWKULARQE-80 URL: https://issues.jboss.org/browse/HAWKULARQE-80 Project: Hawkular QE Issue Type: Task Reporter: Sunil kondkar Assignee: Michael Foley The Add datasource UI is changed. This task is to: 1) Refactor existing cf-ui add datasource test 2) Add a cf-ui test on Creation of XA datasource -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 10:58:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 23 Mar 2017 10:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-79) Test Classic search/Advanced search on middleware pages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar updated HAWKULARQE-79: ------------------------------------ Description: Task to test classic/advanced search options on middleware pages except on topology page. Reference Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1403213 Tasks: * Review existing search test cases * Add any missing test cases * Execute test cases on CFME 5.8.0.7 * Report any bugs * Add automation tests was: Task to test classic/advanced search options on middleware pages except on topology page. Reference Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1403213 Tasks: * Review existing search test cases * Add any missing test cases * Execute test cases on CFME 5.8.0.7 * Report any bugs > Test Classic search/Advanced search on middleware pages > ------------------------------------------------------- > > Key: HAWKULARQE-79 > URL: https://issues.jboss.org/browse/HAWKULARQE-79 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to test classic/advanced search options on middleware pages except on topology page. > Reference Bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1403213 > Tasks: > * Review existing search test cases > * Add any missing test cases > * Execute test cases on CFME 5.8.0.7 > * Report any bugs > * Add automation tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:07:00 2017 From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=) Date: Thu, 23 Mar 2017 11:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8433) [GSS](7.1.0) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: J?rg B?sner created WFLY-8433: --------------------------------- Summary: [GSS](7.1.0) Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8433 URL: https://issues.jboss.org/browse/WFLY-8433 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: J?rg B?sner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:10:00 2017 From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=) Date: Thu, 23 Mar 2017 11:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8433) [GSS](7.1.0) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J?rg B?sner deleted WFLY-8433: ------------------------------ > [GSS](7.1.0) Support socket-binding attribute "client-mapping" in messaging subsystem > ------------------------------------------------------------------------------------- > > Key: WFLY-8433 > URL: https://issues.jboss.org/browse/WFLY-8433 > Project: WildFly > Issue Type: Bug > Reporter: J?rg B?sner > Assignee: Jeff Mesnil > > The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:19:01 2017 From: issues at jboss.org (Stephen Fikes (JIRA)) Date: Thu, 23 Mar 2017 11:19:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8434) [GSS](7.1.0) WFLY-8432 - Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: Stephen Fikes created WFLY-8434: ----------------------------------- Summary: [GSS](7.1.0) WFLY-8432 - Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8434 URL: https://issues.jboss.org/browse/WFLY-8434 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: Stephen Fikes Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:20:00 2017 From: issues at jboss.org (Stephen Fikes (JIRA)) Date: Thu, 23 Mar 2017 11:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8434) [GSS](7.1.0) WFLY-8432 - Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Fikes deleted WFLY-8434: -------------------------------- > [GSS](7.1.0) WFLY-8432 - Support socket-binding attribute "client-mapping" in messaging subsystem > ------------------------------------------------------------------------------------------------- > > Key: WFLY-8434 > URL: https://issues.jboss.org/browse/WFLY-8434 > Project: WildFly > Issue Type: Bug > Reporter: Stephen Fikes > Assignee: Jeff Mesnil > > The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:21:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Thu, 23 Mar 2017 11:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8376) ResourceAdapterPoolAttributesTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka reassigned WFLY-8376: ---------------------------------- Assignee: Martin Simka > ResourceAdapterPoolAttributesTestCase fails with security manager > ----------------------------------------------------------------- > > Key: WFLY-8376 > URL: https://issues.jboss.org/browse/WFLY-8376 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Martin Simka > > *org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase#testModifyPoolAttributes* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ResourceAdapterPoolAttributesTestCase -Dsecurity.manager}} > {code} > SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase.testModifyPoolAttributes: java.lang.AssertionError: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/pool-attributes-test.rar/pool-attributes-test.jar )" of "ModuleClassLoader for Module "deployment.pool-attributes-test.rar" from Service Module Loader") > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.jca.JcaTestsUtil.extractConnectionManager(JcaTestsUtil.java:144) > at org.jboss.as.test.integration.jca.JcaTestsUtil.exctractPoolConfiguration(JcaTestsUtil.java:89) > at org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase.testModifyPoolAttributes(ResourceAdapterPoolAttributesTestCase.java:137) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:25:00 2017 From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=) Date: Thu, 23 Mar 2017 11:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8435) [GSS](7.1.0) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: J?rg B?sner created WFLY-8435: --------------------------------- Summary: [GSS](7.1.0) Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8435 URL: https://issues.jboss.org/browse/WFLY-8435 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: J?rg B?sner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:32:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 23 Mar 2017 11:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-74: ---------------------------------- Attachment: 239pods.png > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:36:00 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Thu, 23 Mar 2017 11:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1494) Problems with parallel agenda In-Reply-To: References: Message-ID: Tibor Zim?nyi created DROOLS-1494: ------------------------------------- Summary: Problems with parallel agenda Key: DROOLS-1494 URL: https://issues.jboss.org/browse/DROOLS-1494 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.0.0.Beta7 Reporter: Tibor Zim?nyi Assignee: Mario Fusco >From doc [1] there can be seen that four benchmarks show problems when run with parallel agenda enabled. Benchmarks _AdvOperators3ExpertBenchmark_ and _RetractFactsFromWmExpertBenchmark_ falled back to single threaded agenda although they doesn't use features that aren't supported with parallel agenda (e.g. like salience). Benchmarks StartsStartedbyFusionBenchmark and UpdateFactsInWmExpertBenchmark shows no gain when using parallel agenda although they contain more partitions. I created runners for debugging here [2], so the benchmarks can be debugged outside of JMH. They are part of master branch in kie-benchmarks, so just pull of new changes is sufficient to get them. [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1hp5lLcmox_NFEUsqNSNZBW2XvkrJWgj0LtEiVvbsCYU/edit?usp=sharing [2] https://github.com/kiegroup/kie-benchmarks/commit/887f758931b02d096f1e870a3145119db315e1af -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:38:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 11:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383132#comment-13383132 ] RH Bugzilla Integration commented on WFLY-7412: ----------------------------------------------- Petr Penicka changed the Status of [bug 1280512|https://bugzilla.redhat.com/show_bug.cgi?id=1280512] from VERIFIED to CLOSED > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: WFLY-7412 > URL: https://issues.jboss.org/browse/WFLY-7412 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stefan Guilhen > Fix For: 11.0.0.Alpha1 > > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > > > > > > > > > > > > > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:45:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 23 Mar 2017 11:45:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen commented on HAWKULARQE-74: --------------------------------------- I hit a hard limit at 239 pods on the node !239pods.png|thumbnail! {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:46:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 23 Mar 2017 11:46:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-8428: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Tomaz Cerar > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:47:00 2017 From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=) Date: Thu, 23 Mar 2017 11:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8436) [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: J?rg B?sner created WFLY-8436: --------------------------------- Summary: [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8436 URL: https://issues.jboss.org/browse/WFLY-8436 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: J?rg B?sner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:50:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 23 Mar 2017 11:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383141#comment-13383141 ] Tomaz Cerar commented on WFLY-8428: ----------------------------------- This is already fixed in my "capabilites" branch. > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Tomaz Cerar > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone at localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 11:50:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 23 Mar 2017 11:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2565) Incorrect permission class-name should throw exception at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383142#comment-13383142 ] ehsavoie Hugonnet commented on WFCORE-2565: ------------------------------------------- After discussing with [~dlofthouse] this should log a warning instead of throwing an error. > Incorrect permission class-name should throw exception at runtime > ----------------------------------------------------------------- > > Key: WFCORE-2565 > URL: https://issues.jboss.org/browse/WFCORE-2565 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > > In case when some permission mapper (tried with constant-permission-mapper and simple-permission-mapper) includes permission with non-existent class-name then it seems that no exception is thrown during runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 12:00:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 23 Mar 2017 12:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383150#comment-13383150 ] Jean-Francois Denise commented on WFCORE-2283: ---------------------------------------------- I have done some experimentation to better expose mandatory arguments (should also apply to complex object properties). An efficient way would be to only expose required attributes first then, once all required attributes have been provided, propose optional ones. This has the benefit to: 1) Better drive users to fill an operation by reducing the amount of exposed arguments to the right set. 2) Reduce the risk to forget required arguments. 3) Comply with existing CLI user experience. High level commands have already this kind of logic. "Required" options are exposed first, then optional options are exposed incrementally. 4) In case there is only one required argument, it will be automatically inlined. Then optionals are proposed. As an example, today: list-add( filter handlers name With such approach: list-add( list-add(name= list-add(name=xxx, filter handlers > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 12:03:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 23 Mar 2017 12:03:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383156#comment-13383156 ] Brian Stansberry commented on WFCORE-2283: ------------------------------------------ Please get input from the UX team on this. (See the JBEAP component list to find the name of the current lead for "User Experience".) > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 12:09:00 2017 From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=) Date: Thu, 23 Mar 2017 12:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8437) [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem In-Reply-To: References: Message-ID: J?rg B?sner created WFLY-8437: --------------------------------- Summary: [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8437 URL: https://issues.jboss.org/browse/WFLY-8437 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: J?rg B?sner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the when creating a . -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 12:37:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 23 Mar 2017 12:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1483) Support default expiration for events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383184#comment-13383184 ] Mario Fusco commented on DROOLS-1483: ------------------------------------- Documented by https://github.com/kiegroup/kie-docs/commit/89fddc9d16a3a0f2183a05200b6cd9916d43f505 > Support default expiration for events > ------------------------------------- > > Key: DROOLS-1483 > URL: https://issues.jboss.org/browse/DROOLS-1483 > Project: Drools > Issue Type: Feature Request > Environment: Drools >= 6.5 in STREAM mode > Reporter: Jochen Welle > Assignee: Mario Fusco > Fix For: 7.0.0.Beta8 > > > We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. > Benefits would be: > * Expiration is guaranteed: either after the specified offset or after the inferred offset. > * Rule authors are not required to include a temporal constraint in all rules. > * Event classes can be designed if the rules are not yet known. > The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m") // fixed expiration offset or > @Expires(value = "10m", type="fixed") // fixed expiration offset > public class MyEvent { > ... > {code} > New behavior: > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m", type="default") // new feature > public class MyEvent { > ... > {code} > The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. > This feature is related to: > * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] > * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 12:42:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Thu, 23 Mar 2017 12:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8376) ResourceAdapterPoolAttributesTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka updated WFLY-8376: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9846 > ResourceAdapterPoolAttributesTestCase fails with security manager > ----------------------------------------------------------------- > > Key: WFLY-8376 > URL: https://issues.jboss.org/browse/WFLY-8376 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Martin Simka > > *org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase#testModifyPoolAttributes* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ResourceAdapterPoolAttributesTestCase -Dsecurity.manager}} > {code} > SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase.testModifyPoolAttributes: java.lang.AssertionError: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/pool-attributes-test.rar/pool-attributes-test.jar )" of "ModuleClassLoader for Module "deployment.pool-attributes-test.rar" from Service Module Loader") > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.jca.JcaTestsUtil.extractConnectionManager(JcaTestsUtil.java:144) > at org.jboss.as.test.integration.jca.JcaTestsUtil.exctractPoolConfiguration(JcaTestsUtil.java:89) > at org.jboss.as.test.integration.jca.poolattributes.ResourceAdapterPoolAttributesTestCase.testModifyPoolAttributes(ResourceAdapterPoolAttributesTestCase.java:137) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 13:53:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 23 Mar 2017 13:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383255#comment-13383255 ] Jean-Francois Denise commented on WFCORE-2283: ---------------------------------------------- Hi [~weeks.c], we are proposing here a way to help Wildly Command Line (CLI) users to identify the required arguments when completing a management operation. 1) One way would be to "tag" exposed arguments to explicit their nature (required vs optional) (eg: asterisk for mandatory, brackets for optional, colouring or any other syntax element). 2) Another way would be to filter arguments. First expose required arguments then, once the operation contains all the mandatory ones, expose optional ones. The second way has today my preference (not a lot of practice of it, just raw prototyping for now): - No syntax marker to decode ("what this '*' means" kind of question) - No confusion between what the completion exposes and what you get when selecting one of these items (tag being removed in the selected argument). - No need for colouring (that color blinds would not take benefit of). Color seems to me not a good idea (specially in a command line/terminal context). - More drive, the user is driven by the completer to choose arguments. - Reduced amount of content exposed to the user. - Allow for optimised cases. This is the case of a single required argument that would be automatically inlined when completing for the first time, the completer would then propose the list of optional arguments (if any). - This is in line with some other part of the CLI where similar filtering is applied to expose command options (as opposed to operation arguments discussed there). With this approach we are loosing the flat list (that contains all arguments) that can be seen as helpful to discover the whole set of arguments in a single action when you have both required and optional arguments. In this case you will discover them all but in 2 steps. Users could think that there are ONLY required attributes although the right way to properly discover the set or operation arguments is by using the help command. help describes the operation synopsis that contains details on required/optional arguments (description and typing). help extract: help /subsystem=logging/logger=sun.rmi:list-add SYNOPSIS list-add(name=, [index=], [value=]) If you are interested by discussing this topic, we could exchange more on it. Thanks. JF > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 14:06:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 14:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used In-Reply-To: References: Message-ID: Carlo de Wolf created JBMETA-400: ------------------------------------ Summary: javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used Key: JBMETA-400 URL: https://issues.jboss.org/browse/JBMETA-400 Project: JBoss Metadata Issue Type: Bug Components: ejb Affects Versions: 10.0.0.Final Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 14:22:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 23 Mar 2017 14:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383264#comment-13383264 ] Brian Stansberry commented on WFCORE-2283: ------------------------------------------ Some random thoughts... One is if I'm looking for something and it isn't proposed, I'm going to be confused and, if it happens a lot, eventually mad. So how to mitigate that? * If they hit tab twice, show them all? * If the list is short, show them all? I think this is particularly relevant if the user has typed something before hitting tab. * Some kind of text output before the list that indicates the list is filtered? Another thing is there are other useful relationships besides whether an attribute is required. For example A -- required, alternate is B B -- required, alternate is A C -- required D -- not required, requires A If I added A to the operation, and then hit tab, I'd want to see D even though it's not required. I configured A which means I've expressed interest in the "A functionality" and therefore the related D should be shown. (I also wouldn't want to see B since it is illegal now.) The downside to all this stuff I mention here is there's no longer any obvious to the user rule to explain when stuff appears. So it could seem a bit mysterious. Having an easy way to get an unfiltered list (e.g. second tab) would help mitigate that. An easy way to get the unfiltered list is also a built-in workaround to the bugs that are likely to crop up with this. > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 14:22:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 23 Mar 2017 14:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2532) Some logging tests fail with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383265#comment-13383265 ] James Perkins commented on WFCORE-2532: --------------------------------------- We likely just need to wrap the {{TestSuiteEnvironment.getSystemProperty()}} with privileged block. Any test using that will have issues. In the logging cases it's {{TestSuiteEnvironment.getHttpAddress()}} that's causing the issue. > Some logging tests fail with security manager in WF core > -------------------------------------------------------- > > Key: WFCORE-2532 > URL: https://issues.jboss.org/browse/WFCORE-2532 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > > * *org.jboss.as.test.integration.logging.operations.CustomFormattersTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerOperationsTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.operations.Log4jCustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLog4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.LoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase* > * *org.jboss.as.test.integration.logging.profiles.NonExistingProfileTestCase* > * *org.jboss.as.test.integration.logging.syslog.SyslogHandlerTestCase* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=org.jboss.as.test.integration.logging.**.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging1.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging1.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging1.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging1.jar )\" of \"ModuleClassLoader for Module \"deployment.logging1.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging1.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.test.integration.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:168) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:314) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:304) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.testProfiles(LoggingProfilesTestCase.java:201 > {code} > * *org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase* > * *org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase* > * *org.jboss.as.test.manualmode.logging.PerDeployLoggingTestCase* > * *org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase* > * *org.jboss.as.test.manualmode.logging.SizeAppenderRestartTestCase* > * *org.jboss.as.test.manualmode.logging.SyslogIsNotAvailableDuringServerBootTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -Dtest=org.jboss.as.test.manualmode.logging.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging-test.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging-test.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging-test.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging-test.jar )\" of \"ModuleClassLoader for Module \"deployment.logging-test.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging-test.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.wildfly.core.testrunner.ServerController.deploy(ServerController.java:92) > at org.jboss.as.test.manualmode.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:197) > at org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase.startContainer(Log4jAppenderTestCase.java:93) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 14:40:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 14:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1026) Release WildFly Elytron 1.1.0.Beta33 In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1026: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta33 Key: ELY-1026 URL: https://issues.jboss.org/browse/ELY-1026 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta33 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 14:57:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 14:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2572) Upgrade WildFly Elytron to 1.1.0.Beta33 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2572: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta33 Key: WFCORE-2572 URL: https://issues.jboss.org/browse/WFCORE-2572 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta11 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 14:58:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 14:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2573) Upgrade to WildFly Elytron Tool 1.0.0.Alpha4 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2573: ---------------------------------------- Summary: Upgrade to WildFly Elytron Tool 1.0.0.Alpha4 Key: WFCORE-2573 URL: https://issues.jboss.org/browse/WFCORE-2573 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta11 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 15:27:00 2017 From: issues at jboss.org (Farah Juma (JIRA)) Date: Thu, 23 Mar 2017 15:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8438) EJBComponentDescription : possible NPE on securityRoles In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma moved JBEAP-9854 to WFLY-8438: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8438 (was: JBEAP-9854) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.1.0.DR12) > EJBComponentDescription : possible NPE on securityRoles > ------------------------------------------------------- > > Key: WFLY-8438 > URL: https://issues.jboss.org/browse/WFLY-8438 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Farah Juma > Assignee: Farah Juma > > In https://github.com/wildfly/wildfly/commit/38f8f5915b40d036bd0fd1a904d6a13916f3fa2c#diff-faf7ca63d4b901f1bff0697491c8f5ddL1147 you added check on {{if (securityRoles != null)}}. > securityRoles is not checked few lines below your check (in different if block) > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponentDescription.java#L1162 (securityRoles.getSecurityRoleNamesByPrincipal ... ) > I suggest to change https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponentDescription.java#L1158 from > {code} > if (runAsPrincipal != null) { > {code} > to > {code} > if ((securityRoles != null) && (runAsPrincipal != null)) { > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 15:32:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Thu, 23 Mar 2017 15:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf reassigned JBMETA-400: ------------------------------------ Assignee: (was: Carlo de Wolf) > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 15:58:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 23 Mar 2017 15:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383264#comment-13383264 ] Brian Stansberry edited comment on WFCORE-2283 at 3/23/17 3:57 PM: ------------------------------------------------------------------- Some random thoughts... One is if I'm looking for something and it isn't proposed, I'm going to be confused and, if it happens a lot, eventually mad. So how to mitigate that? * If they hit tab twice, show them all? * If the list is short, show them all? I think this is particularly relevant if the user has typed something before hitting tab. * Some kind of text output before the list that indicates the list is filtered? Another thing is there are other useful relationships besides whether an attribute is required. For example A -- required, alternative is B B -- required, alternative is A C -- required D -- not required, requires A If I added A to the operation, and then hit tab, I'd want to see D even though it's not required. I configured A which means I've expressed interest in the "A functionality" and therefore the related D should be shown. (I also wouldn't want to see B since it is illegal now.) The downside to all this stuff I mention here is there's no longer any obvious to the user rule to explain when stuff appears. So it could seem a bit mysterious. Having an easy way to get an unfiltered list (e.g. second tab) would help mitigate that. An easy way to get the unfiltered list is also a built-in workaround to the bugs that are likely to crop up with this. was (Author: brian.stansberry): Some random thoughts... One is if I'm looking for something and it isn't proposed, I'm going to be confused and, if it happens a lot, eventually mad. So how to mitigate that? * If they hit tab twice, show them all? * If the list is short, show them all? I think this is particularly relevant if the user has typed something before hitting tab. * Some kind of text output before the list that indicates the list is filtered? Another thing is there are other useful relationships besides whether an attribute is required. For example A -- required, alternate is B B -- required, alternate is A C -- required D -- not required, requires A If I added A to the operation, and then hit tab, I'd want to see D even though it's not required. I configured A which means I've expressed interest in the "A functionality" and therefore the related D should be shown. (I also wouldn't want to see B since it is illegal now.) The downside to all this stuff I mention here is there's no longer any obvious to the user rule to explain when stuff appears. So it could seem a bit mysterious. Having an easy way to get an unfiltered list (e.g. second tab) would help mitigate that. An easy way to get the unfiltered list is also a built-in workaround to the bugs that are likely to crop up with this. > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 16:40:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 23 Mar 2017 16:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5274) EJB IOR contains wrong port (non-SSL port) information when SSL is required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383344#comment-13383344 ] RH Bugzilla Integration commented on WFLY-5274: ----------------------------------------------- Petr Penicka changed the Status of [bug 1259902|https://bugzilla.redhat.com/show_bug.cgi?id=1259902] from VERIFIED to CLOSED > EJB IOR contains wrong port (non-SSL port) information when SSL is required > --------------------------------------------------------------------------- > > Key: WFLY-5274 > URL: https://issues.jboss.org/browse/WFLY-5274 > Project: WildFly > Issue Type: Bug > Components: IIOP > Reporter: Derek Horton > Assignee: Tomasz Adamski > > Description of problem: > - Configure JBoss to only allow IIOP connections over SSL > - It is possible to do this, but the configuration is confusing (possibly a bug) > Details of the setup/issue: > - When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port > - Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port > - However, the IOR tells client to connect to non-ssl port ...even though its not listening on it > String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath; > // lookup the IIOP EJB > Object iiopObj = ctx.lookup(lookup); > // the call to the EJB will fail due to the port being wrong non-ssl vs ssl > - The workaround is to use the following ior-setting to correct the port settings in the IOR > /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required) > - Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 19:18:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 23 Mar 2017 19:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-24) HOSA --- Hawkular Agent for Openshift In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-24: ---------------------------------- Description: Top level task for HOSA. All the work required goes here as sub-tasks. Issues: - [BZ1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] was: Top level task for HOSA. All the work required goes here as sub-tasks. > HOSA --- Hawkular Agent for Openshift > ------------------------------------- > > Key: HAWKULARQE-24 > URL: https://issues.jboss.org/browse/HAWKULARQE-24 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: viet nguyen > > Top level task for HOSA. > All the work required goes here as sub-tasks. > Issues: > - [BZ1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 19:27:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Thu, 23 Mar 2017 19:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-74: ---------------------------------- Attachment: 30mins-ago5.txt 30mins-ago4.txt > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30mins-ago4.txt, 30mins-ago5.txt > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 19:33:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 23 Mar 2017 19:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8439) Unregistering node throws error: MEM: Can't update or insert context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9863 to WFLY-8439: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8439 (was: JBEAP-9863) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: mod_cluster Web (Undertow) (was: mod_cluster) (was: Web (Undertow)) Affects Version/s: (was: 7.1.0.DR14) > Unregistering node throws error: MEM: Can't update or insert context > -------------------------------------------------------------------- > > Key: WFLY-8439 > URL: https://issues.jboss.org/browse/WFLY-8439 > Project: WildFly > Issue Type: Bug > Components: mod_cluster, Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Labels: mod_cluster > > New error message in proxy balancer log > {noformat} > 2017-03-21 15:22:24,957 INFO [io.undertow] (default task-23) UT005047: Unregistering context wildfly-services, from node jboss-eap-7.1-1 > 2017-03-21 15:22:24,962 ERROR [io.undertow] (default task-23) UT005043: Error in processing MCMP commands: Type:MEM, Mess: MEM: Can't update or insert context > 2017-03-21 15:22:28,694 INFO [io.undertow] (default task-29) UT005047: Unregistering context wildfly-services, from node jboss-eap-7.1-2 > 2017-03-21 15:22:28,696 ERROR [io.undertow] (default task-29) UT005043: Error in processing MCMP commands: Type:MEM, Mess: MEM: Can't update or insert context > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 19:34:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 19:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1026) Release WildFly Elytron 1.1.0.Beta33 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-1026. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta33 > ------------------------------------ > > Key: ELY-1026 > URL: https://issues.jboss.org/browse/ELY-1026 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta33 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 19:36:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 19:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in CredentialStore with JDK-8005408 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-926: --------------------------------- Fix Version/s: 1.1.0.Beta23 (was: 1.1.0.Beta35) > PKCS#12 support in CredentialStore with JDK-8005408 > --------------------------------------------------- > > Key: ELY-926 > URL: https://issues.jboss.org/browse/ELY-926 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Environment: JDK with JDK-8005408 > Reporter: Zoran Regvart > Assignee: Zoran Regvart > Priority: Minor > Fix For: 1.1.0.Beta23 > > > JDK with [JDK-8005408|http://bugs.java.com/view_bug.do?bug_id=8005408] changed the behaviour of PKCS#12 KeyStore so it will use SecretKeyFactory to convert from SecretKeySpec to SecretKey. So a SecretKeyFactorySpi implementation is needed to support PKCS#7 Data OID used when storing data as SecretKeys in the PKCS#12 KeyStore. > This relates to ELY-920 and the test failure on JDK 1.8.0_74. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 19:43:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 19:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8440) Backport latest Elytron Integration changes In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8440: -------------------------------------- Summary: Backport latest Elytron Integration changes Key: WFLY-8440 URL: https://issues.jboss.org/browse/WFLY-8440 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:13:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2546) Typo in description of Elytron aggregate-principal-transformer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2546: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Typo in description of Elytron aggregate-principal-transformer > -------------------------------------------------------------- > > Key: WFCORE-2546 > URL: https://issues.jboss.org/browse/WFCORE-2546 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Fix For: 3.0.0.Beta11 > > > There is typo in description of Elytron aggregate-principal-transformer in CLI. There is {{principa}} instead of {{principal}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:13:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:13:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2399) Removing and re-adding alias to credential store leads to Duplicate resource failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2399: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Removing and re-adding alias to credential store leads to Duplicate resource failure > ------------------------------------------------------------------------------------ > > Key: WFCORE-2399 > URL: https://issues.jboss.org/browse/WFCORE-2399 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store > Fix For: 3.0.0.Beta11 > > > When an alias is removed from a credential store and added once more, the {{add}} operation fails with Duplicate resource message. > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8144 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:13:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:13:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2455) Empty secret-value is not allowed in credential stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2455: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Empty secret-value is not allowed in credential stores > ------------------------------------------------------- > > Key: WFCORE-2455 > URL: https://issues.jboss.org/browse/WFCORE-2455 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: credential-store > Fix For: 3.0.0.Beta11 > > > It's not possible to add an entry with empty secret-value into a credential store. > Masking the fact the password is empty is a valid scenario. > {code} > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0155: 'secret-value' may not be null", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=elytron/credential-store=cred-store-default/alias=emptysecret:add(secret-value="") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter secret-value. Values must have a minimum length of 1 characters", > "rolled-back" => true > } > {code} > *Unignore tests* > When this issue is fixed, unignore (and fix if needed) related tests in {{testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/application/}}. Thanks. > {code} > git grep WFLY-8143 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2409) Review elytron kerberos-security-factory resource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2409: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 4.0.0.Alpha1) > Review elytron kerberos-security-factory resource > ------------------------------------------------- > > Key: WFCORE-2409 > URL: https://issues.jboss.org/browse/WFCORE-2409 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: user_experience > Fix For: 3.0.0.Beta11 > > > * {{mechanism-oids}} > ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code} > ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. > * {{minimum-remaining-lifetime}} > ** please, specify units in documentation, e.g. seconds/minutes > * {{relative-to}} > ** as just path reference can be used here, probably should be just "expressions-allowed" => false > ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute." > * {{server}} > ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation. > * {{for-hosts}} > ** comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:16:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2570) Explain the meaning of maximum-session-cache-size and session-timeout default values. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2570: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Explain the meaning of maximum-session-cache-size and session-timeout default values. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2570 > URL: https://issues.jboss.org/browse/WFCORE-2570 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Fix For: 3.0.0.Beta11 > > > The default values 0 of maximum-session-cache-size and session-timeout of Elytron will not override the JVM defaults. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:20:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8397) Create test cases for Elytron Principal Transformers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8397: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Create test cases for Elytron Principal Transformers > ---------------------------------------------------- > > Key: WFLY-8397 > URL: https://issues.jboss.org/browse/WFLY-8397 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > Fix For: 11.0.0.Alpha1 > > > Create test cases for following Elytron Principal Transformers: > * constant-principal-transformer > * regex-principal-transformer > * regex-validating-principal-transformer > * chained-principal-transformer > Test case for aggregate-principal-transformer cannot developed due to WFCORE-2547. Once meaning of aggregate-principal-transformer will be revisited then appropriate test case will be added. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:21:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8429) Pooled connection factory with default discovery group is not able to connect to cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8429: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Pooled connection factory with default discovery group is not able to connect to cluster > ---------------------------------------------------------------------------------------- > > Key: WFLY-8429 > URL: https://issues.jboss.org/browse/WFLY-8429 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > Test Scenario: > * Start 1st EAP 7.1 server with deployed queues InQueue and OutQueue > * Start 2nd EAP 7.1 server with MDB which consumes messages from InQueue and resends to OutQueue > ** pooled-connection-factory is using default {{discovery-group="dg-group1"}} to get connectors to 1st EAP 7.1 server > * Send messages to InQueue and consume from OutQueue > Pass Criteria: Number of send and received messages is the same. > Actual Result: > MDB does not start to consume messages from InQueue. > Expected Result: > MDB will resend messages from InQueue to OutQueue. > Attaching configuration and trace logs from test. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:22:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8421) Upgrade jboss-ejb-client to 4.0.0.Beta22 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8421: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Upgrade jboss-ejb-client to 4.0.0.Beta22 > ---------------------------------------- > > Key: WFLY-8421 > URL: https://issues.jboss.org/browse/WFLY-8421 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:22:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8423) Transaction client does not have access to EJB client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8423: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Transaction client does not have access to EJB client > ----------------------------------------------------- > > Key: WFLY-8423 > URL: https://issues.jboss.org/browse/WFLY-8423 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 11.0.0.Alpha1 > > > Missing import in the module.xml for the tx client. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 20:23:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 23 Mar 2017 20:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8426) EJBClientDescriptorTestCase doesn't do a proper clean-up In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8426: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > EJBClientDescriptorTestCase doesn't do a proper clean-up > -------------------------------------------------------- > > Key: WFLY-8426 > URL: https://issues.jboss.org/browse/WFLY-8426 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Fix For: 11.0.0.Alpha1 > > > The ServerSetupTask instance {{EJBClientDescriptorTestCase.EJBClientDescriptorTestCaseSetup}} has a wrong order of operations in {{tearDown}} method, so already the first operation fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 21:25:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 23 Mar 2017 21:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8441) Stack containing encrypt-protocol throws IllegalStateException at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9868 to WFLY-8441: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8441 (was: JBEAP-9868) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: No Release (was: 7.1.0.DR15) > Stack containing encrypt-protocol throws IllegalStateException at runtime > -------------------------------------------------------------------------- > > Key: WFLY-8441 > URL: https://issues.jboss.org/browse/WFLY-8441 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: No Release > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > Looks to be the result of a botched merge/rebase. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 23 21:33:00 2017 From: issues at jboss.org (Mahesh Reddy (JIRA)) Date: Thu, 23 Mar 2017 21:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahesh Reddy updated WFLY-8160: ------------------------------- Attachment: file-leak-detector_output.txt > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 02:09:00 2017 From: issues at jboss.org (Jim Ma (JIRA)) Date: Fri, 24 Mar 2017 02:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8442) resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor In-Reply-To: References: Message-ID: Jim Ma created WFLY-8442: ---------------------------- Summary: resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor Key: WFLY-8442 URL: https://issues.jboss.org/browse/WFLY-8442 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 10.1.0.Final Reporter: Jim Ma Assignee: Jim Ma Fix For: 11.0.0.Alpha1 resteasy.scan , resteasy.scan.provider and resteasy.scan.resources are already processed in JaxrsScanningProcessor. There is no effect to handle it in JaxrsIntegrationProcessor -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 02:25:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Fri, 24 Mar 2017 02:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8443) Elytron, specify cipher-suite-filter default In-Reply-To: References: Message-ID: Martin Choma created WFLY-8443: ---------------------------------- Summary: Elytron, specify cipher-suite-filter default Key: WFLY-8443 URL: https://issues.jboss.org/browse/WFLY-8443 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker Elytron comes with default use-cipher-suites-order = true. {code} "use-cipher-suites-order" => { "type" => BOOLEAN, "description" => "To honor local cipher suites preference.", "expressions-allowed" => true, "required" => false, "nillable" => true, "default" => true, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } {code} It means honor server cipher suites preference. Because of that Elytron has to provide also some carefully selected cipher-suite-filter default {code} "cipher-suite-filter" => { "type" => STRING, "description" => "The filter to apply to specify the enabled cipher suites.", "expressions-allowed" => true, "required" => false, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } {code} Nowadays default is just {{org.wildfly.security.ssl.CipherSuiteSelector#openSslDefault()}} ("DEFAULT") -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 04:11:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 24 Mar 2017 04:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383481#comment-13383481 ] Tomaz Cerar commented on WFLY-8160: ----------------------------------- Looking at the output of the file leak detector, there are no leaks in any of WildFly related code. However, you do have somewhat a problem with **LOTS** of open sockets that are opened by zeromq. This is the trace that repeates pretty much through the whole file: {noformat} 2017-03-23 17:30:38,412 ERROR [AbstractLoggingWriter] (iothread-2) Opened socket channel by thread:iothread-2 on Thu Mar 23 17:30:38 PDT 2017 at sun.nio.ch.SocketChannelImpl.(SocketChannelImpl.java:108) at sun.nio.ch.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:60) at java.nio.channels.SocketChannel.open(SocketChannel.java:145) at zmq.TcpConnecter.open(TcpConnecter.java:292) at zmq.TcpConnecter.startConnecting(TcpConnecter.java:215) at zmq.TcpConnecter.timerEvent(TcpConnecter.java:206) at zmq.IOObject.timerEvent(IOObject.java:129) at zmq.PollerBase.executeTimers(PollerBase.java:131) at zmq.Poller.run(Poller.java:187) at java.lang.Thread.run(Thread.java:745) {noformat} In linux open socket channel also consumes file descriptor and this is most probably your root cause of the issue. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 04:21:00 2017 From: issues at jboss.org (Mahesh Reddy (JIRA)) Date: Fri, 24 Mar 2017 04:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383486#comment-13383486 ] Mahesh Reddy commented on WFLY-8160: ------------------------------------ Regarding the lots of open sockets, For all these open sockets, there are equal number of close sockets. So this is not related to the open pipe leak. If i give the java processId to lsof -p and again check after webservice response, i see one open pipe gets added after webservice response. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 04:21:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 24 Mar 2017 04:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2165) TP.receive() should also handle InputStreams In-Reply-To: References: Message-ID: Bela Ban created JGRP-2165: ------------------------------ Summary: TP.receive() should also handle InputStreams Key: JGRP-2165 URL: https://issues.jboss.org/browse/JGRP-2165 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.2 Currently, {{TP.receive()}} is passed a byte[] buffer as parameter. This is OK for UDP and TCP_NIO2, however, in TCP we're dealing with a socket input stream. TcpConnection reads the length, then copies {{length}} bytes into a byte[] buffer and finally calls TP.receive() with the byte[] buffer as argument. The byte[] buffer and the copying of read data into it is superfluous if TP.receive() could also accept input streams as argument. Therefore introduce an additional {{TP.receive(InputStream in, int offset, int length}}, which reads directly from the socket's input stream and gets rid of the intermediate byte buffer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 04:35:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Fri, 24 Mar 2017 04:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka reassigned WFCORE-2534: ------------------------------------ Assignee: Martin Simka > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: Martin Simka > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 04:49:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 24 Mar 2017 04:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383510#comment-13383510 ] Tomaz Cerar commented on WFLY-8160: ----------------------------------- Well, then the trace you provided doesn't include everything. You can also configure the leak detector agent to dump only non-closed descriptors, this way it is easier to find culprit. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p , And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 06:32:01 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Fri, 24 Mar 2017 06:32:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf reassigned JBMETA-400: ------------------------------------ Assignee: Carlo de Wolf > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 06:37:00 2017 From: issues at jboss.org (James Netherton (JIRA)) Date: Fri, 24 Mar 2017 06:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8444) Upgrade proton to align with Artemis In-Reply-To: References: Message-ID: James Netherton created WFLY-8444: ------------------------------------- Summary: Upgrade proton to align with Artemis Key: WFLY-8444 URL: https://issues.jboss.org/browse/WFLY-8444 Project: WildFly Issue Type: Component Upgrade Components: JMS Reporter: James Netherton Assignee: Jeff Mesnil I'm working on integrating the Apache Camel AMQP component with WildFly: https://github.com/wildfly-extras/wildfly-camel/issues/1405 I'd like to make use of WildFly's existing {{org.apache.qpid.proton}} module. However, the Proton libraries are quite old. I see that the Artemis version referenced on the WildFly master branch is 1.5.3. Can we align the Proton version used in WildFly with the one used by Artemis 1.5.3 (0.16.0)? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 06:47:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Fri, 24 Mar 2017 06:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf updated JBMETA-400: --------------------------------- Git Pull Request: https://github.com/jboss/metadata/pull/110 > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:04:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 24 Mar 2017 07:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-644. ------------------------------------- Resolution: Out of Date The JBoss CLI now uses WildFly Elytron authentication client based configuration. > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta11 > > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:05:00 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Fri, 24 Mar 2017 07:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-64) [QE] - JMAN4-126 - Enable and Disable deployments in an Server Group In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Yadav reassigned HAWKULARQE-64: -------------------------------------- Assignee: Prachi Yadav (was: Michael Foley) > [QE] - JMAN4-126 - Enable and Disable deployments in an Server Group > -------------------------------------------------------------------- > > Key: HAWKULARQE-64 > URL: https://issues.jboss.org/browse/HAWKULARQE-64 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > > See [JMAN4-126|https://issues.jboss.org/browse/JMAN4-126] > Dev task for it [HAWKULAR-1165|https://issues.jboss.org/browse/HAWKULAR-1165] > This is 5.0 release planed feature, but is in development of 4.5. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:21:00 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Fri, 24 Mar 2017 07:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-69) Regression Test Hawkular Inventory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Yadav reassigned HAWKULARQE-69: -------------------------------------- Assignee: Prachi Yadav (was: Michael Foley) > Regression Test Hawkular Inventory > ---------------------------------- > > Key: HAWKULARQE-69 > URL: https://issues.jboss.org/browse/HAWKULARQE-69 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Prachi Yadav > > Place-holder task, for now. > Hawkular Inventory is being redesigned, and expected to be included in the 4.5 release. Will need to regression test around Inventory features. > Note: The use of Postgres DB for Inventory data will be going away. > Further details are forthcoming. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:21:00 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Fri, 24 Mar 2017 07:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-76) Add Provider - Security Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Yadav reassigned HAWKULARQE-76: -------------------------------------- Assignee: Prachi Yadav (was: Michael Foley) > Add Provider - Security Protocol > -------------------------------- > > Key: HAWKULARQE-76 > URL: https://issues.jboss.org/browse/HAWKULARQE-76 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > Priority: Critical > > In Add New Provider page there is a new field: "Security Protocol", for validating connection. > It needs to be tested and automated in Provider CRUD tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:28:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Fri, 24 Mar 2017 07:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka reassigned WFCORE-2534: ------------------------------------ Assignee: Brian Stansberry (was: Martin Simka) > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: Brian Stansberry > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:29:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Fri, 24 Mar 2017 07:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka reassigned WFCORE-2534: ------------------------------------ Assignee: (was: Brian Stansberry) > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:34:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Fri, 24 Mar 2017 07:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383666#comment-13383666 ] Jean-Francois Denise commented on WFCORE-2283: ---------------------------------------------- [~brian.stansberry] something that is missing in a filtering only approach is the ability to easily (without having to go to help) answer the question: Do all the required attributes have been set? If we complement the approach with a "Double Tab" of something like 500ms, we could expose all the remaining arguments annotated with relationships/attributes. ('*', , ...) It seems that required, requires and alternatives would be doable with the filtering approach: - Alternatives should be hidden as soon as a choice has been made. - Partly typed argument name should be completed if it exists and all its dependencies are resolved, being required or not. - Argument that depends on the presence of other arguments should be hidden until all the dependencies are present. That is in line with the way Commands are exposing options. - Requires relationship overrides the required attribute. Any attribute is exposed as soon as all its dependencies (if any) are resolved. In your example, let's imagine that: D - not required, requires A and C. E - required As soon as A and C are present, D is exposed along E although D is not required. Seems that users wouldn't have to think too much. They press Tab, and choose the argument they want to set. If lost, they press Tab twice and decode the exposed relationships. If that is not enough, they go to help. Going to help requires to clear the current line and type help , then type again the operation (generally Paste again the operation that would have been previously copied). This is very inefficient and requires too much context switching. An inline help could be designed...more thinking needed there... Double tab, could be a first step toward it. JF > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:47:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 24 Mar 2017 07:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1494) Problems with parallel agenda In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383681#comment-13383681 ] Mario Fusco commented on DROOLS-1494: ------------------------------------- The reason why AdvOperators3ExpertBenchmark and RetractFactsFromWmExpertBenchmark are falling back to the single threaded agenda is because, while it's true that there are multiple partitions, each OTN has only one single partition below it. I corrected this behaviour and allowed parallel evaluation with this pull request: https://github.com/kiegroup/drools/pull/1163 However I ran some preliminary benchmark and found that in those case the parallel engine is slower than the sequential one, so I'd keep the fallback and drop that pull request. [~tzimanyi] please also give a run at my pull request and let me know if you'll also find same results. In case you believe that the parallel engine is faster also in that case (I don't think so) feel free to merge my pull request. Regarding the other 2 benchmarks that show no gain when running in parallel I believe we have a quite similar situation. There each OTN only has only 2 partitions below it (e.g. for constraints firstName == null and firstName != null) and then it is not able to fully leverage the 8-core cpu. > Problems with parallel agenda > ----------------------------- > > Key: DROOLS-1494 > URL: https://issues.jboss.org/browse/DROOLS-1494 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zim?nyi > Assignee: Mario Fusco > Labels: reported-by-qe > > From doc [1] there can be seen that four benchmarks show problems when run with parallel agenda enabled. > Benchmarks _AdvOperators3ExpertBenchmark_ and _RetractFactsFromWmExpertBenchmark_ > falled back to single threaded agenda although they doesn't use features that aren't supported with parallel agenda (e.g. like salience). > Benchmarks StartsStartedbyFusionBenchmark and UpdateFactsInWmExpertBenchmark shows no gain when using parallel agenda although they contain more partitions. > I created runners for debugging here [2], so the benchmarks can be debugged outside of JMH. They are part of master branch in kie-benchmarks, so just pull of new changes is sufficient to get them. > [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1hp5lLcmox_NFEUsqNSNZBW2XvkrJWgj0LtEiVvbsCYU/edit?usp=sharing > [2] https://github.com/kiegroup/kie-benchmarks/commit/887f758931b02d096f1e870a3145119db315e1af -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:54:02 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 24 Mar 2017 07:54:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8445) Non file-based keystores used in ssl configuration don't allow to set key alias In-Reply-To: References: Message-ID: Josef Cacek created WFLY-8445: --------------------------------- Summary: Non file-based keystores used in ssl configuration don't allow to set key alias Key: WFLY-8445 URL: https://issues.jboss.org/browse/WFLY-8445 Project: WildFly Issue Type: Bug Components: Domain Management, Security Reporter: Josef Cacek Assignee: Brian Stansberry Priority: Critical Management model for SSL in security realms allows to configure alias to be used for the keystore. Neverhteless this configuration doesn't work for non-file-based keystores. E.g. {code:xml} {code} The problem is probably in {{ProviderKeyManagerService}} class which has no evidence about the alias. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 07:58:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 24 Mar 2017 07:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2574) Ensure wrap on server-ssl-context default to false In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2574: ---------------------------------------- Summary: Ensure wrap on server-ssl-context default to false Key: WFCORE-2574 URL: https://issues.jboss.org/browse/WFCORE-2574 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 3.0.0.Beta11 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:10:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 24 Mar 2017 08:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2575) Non file-based keystores used in ssl configuration don't allow to set key alias In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-8445 to WFCORE-2575: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2575 (was: WFLY-8445) Component/s: Domain Management Security (was: Domain Management) (was: Security) > Non file-based keystores used in ssl configuration don't allow to set key alias > ------------------------------------------------------------------------------- > > Key: WFCORE-2575 > URL: https://issues.jboss.org/browse/WFCORE-2575 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Josef Cacek > Assignee: Brian Stansberry > Priority: Critical > > Management model for SSL in security realms allows to configure alias to be used for the keystore. Neverhteless this configuration doesn't work for non-file-based keystores. > E.g. > {code:xml} > > alias="server-ssl" keystore-password="thepassword" /> > > {code} > The problem is probably in {{ProviderKeyManagerService}} class which has no evidence about the alias. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:10:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 24 Mar 2017 08:10:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2575) Non file-based keystores used in ssl configuration don't allow to set key alias In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned WFCORE-2575: ---------------------------------------- Assignee: Darran Lofthouse (was: Brian Stansberry) > Non file-based keystores used in ssl configuration don't allow to set key alias > ------------------------------------------------------------------------------- > > Key: WFCORE-2575 > URL: https://issues.jboss.org/browse/WFCORE-2575 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Management model for SSL in security realms allows to configure alias to be used for the keystore. Neverhteless this configuration doesn't work for non-file-based keystores. > E.g. > {code:xml} > > alias="server-ssl" keystore-password="thepassword" /> > > {code} > The problem is probably in {{ProviderKeyManagerService}} class which has no evidence about the alias. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:11:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 24 Mar 2017 08:11:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2575) Non file-based keystores used in ssl configuration don't allow to set key alias In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2575: ------------------------------------- Issue Type: Feature Request (was: Bug) > Non file-based keystores used in ssl configuration don't allow to set key alias > ------------------------------------------------------------------------------- > > Key: WFCORE-2575 > URL: https://issues.jboss.org/browse/WFCORE-2575 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Management model for SSL in security realms allows to configure alias to be used for the keystore. Neverhteless this configuration doesn't work for non-file-based keystores. > E.g. > {code:xml} > > alias="server-ssl" keystore-password="thepassword" /> > > {code} > The problem is probably in {{ProviderKeyManagerService}} class which has no evidence about the alias. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:21:01 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Fri, 24 Mar 2017 08:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf resolved JBMETA-400. ---------------------------------- Resolution: Done > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > Fix For: 10.0.1.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:21:01 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Fri, 24 Mar 2017 08:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf updated JBMETA-400: --------------------------------- Fix Version/s: 10.0.1.Final > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > Fix For: 10.0.1.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:50:01 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 24 Mar 2017 08:50:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8446) Infinispan store=file resource needs capability references for path resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9881 to WFLY-8446: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8446 (was: JBEAP-9881) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR14) > Infinispan store=file resource needs capability references for path resolution > ------------------------------------------------------------------------------ > > Key: WFLY-8446 > URL: https://issues.jboss.org/browse/WFLY-8446 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, one can create a file-store with an invalid relative-to path reference, which will not be discovered until runtime. This should be validated by the model via capability references. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:53:01 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 24 Mar 2017 08:53:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8446) Infinispan store=file resource needs capability references for path resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383749#comment-13383749 ] Paul Ferraro edited comment on WFLY-8446 at 3/24/17 8:52 AM: ------------------------------------------------------------- Requires wildfly-core-3.0.0.Beta11 was (Author: pferraro): Required wildfly-core-3.0.0.Beta11 > Infinispan store=file resource needs capability references for path resolution > ------------------------------------------------------------------------------ > > Key: WFLY-8446 > URL: https://issues.jboss.org/browse/WFLY-8446 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, one can create a file-store with an invalid relative-to path reference, which will not be discovered until runtime. This should be validated by the model via capability references. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 08:53:01 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 24 Mar 2017 08:53:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8446) Infinispan store=file resource needs capability references for path resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383749#comment-13383749 ] Paul Ferraro commented on WFLY-8446: ------------------------------------ Required wildfly-core-3.0.0.Beta11 > Infinispan store=file resource needs capability references for path resolution > ------------------------------------------------------------------------------ > > Key: WFLY-8446 > URL: https://issues.jboss.org/browse/WFLY-8446 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, one can create a file-store with an invalid relative-to path reference, which will not be discovered until runtime. This should be validated by the model via capability references. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 09:04:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 24 Mar 2017 09:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1027) CS tool, Parameter --salt requires --iteration and vice versa In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1027: --------------------------------- Summary: CS tool, Parameter --salt requires --iteration and vice versa Key: ELY-1027 URL: https://issues.jboss.org/browse/ELY-1027 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse If I use only one parameter from --salt or --iteration then this one is ignored and result password is in clear text. {code} java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt="abcdefgh" {code} Result of this command is: {code} Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) {code} *There is expected error.* Please add there this constraint: parameter --salt requires --iteration and vice versa -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 09:04:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 24 Mar 2017 09:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1027) CS tool, Parameter --salt requires --iteration and vice versa In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1027: ------------------------------ Component/s: Command-Line Tool > CS tool, Parameter --salt requires --iteration and vice versa > ------------------------------------------------------------- > > Key: ELY-1027 > URL: https://issues.jboss.org/browse/ELY-1027 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > If I use only one parameter from --salt or --iteration then this one is ignored and result password is in clear text. > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt="abcdefgh" > {code} > Result of this command is: > {code} > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > *There is expected error.* > Please add there this constraint: parameter --salt requires --iteration and vice versa -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 09:16:00 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Fri, 24 Mar 2017 09:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1495) Partition also ObjectTypeNodes when using parallel agenda In-Reply-To: References: Message-ID: Tibor Zim?nyi created DROOLS-1495: ------------------------------------- Summary: Partition also ObjectTypeNodes when using parallel agenda Key: DROOLS-1495 URL: https://issues.jboss.org/browse/DROOLS-1495 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.0.0.Beta7 Reporter: Tibor Zim?nyi Assignee: Mario Fusco Priority: Minor Currently we don't parallelize ObjectTypeNodes. They are part of MAIN partition. The parallelization starts then after OTNs. This limitation doesn't introduce performance gains for scenarios, where only one partition is after each OTN. The better approach would be to have the Rete network partitioned right from Entry Point. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 09:18:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 24 Mar 2017 09:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8447) Change FD to FD_ALL in default TCP JGroups stack In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9884 to WFLY-8447: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8447 (was: JBEAP-9884) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR14) > Change FD to FD_ALL in default TCP JGroups stack > ------------------------------------------------ > > Key: WFLY-8447 > URL: https://issues.jboss.org/browse/WFLY-8447 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > I was speaking to [~belaban] on performance tuning recommendations for the upcoming EAP 7.1 Performance Tuning Guide. > He mentioned that he could see no reason why the default JGroups TCP stack should be using FD instead of FD_ALL for failure detection. (the UDP stack already has FD_ALL as the default). > Rather than instruct customers to change the protocol manually, it would be better if the default TCP stack could be changed to use FD_ALL by default. > Here are the default stacks taken from `standalone-ha.xml` in 7.1.0.DR14: > {code:xml} > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 09:19:00 2017 From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=) Date: Fri, 24 Mar 2017 09:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1494) Problems with parallel agenda In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383792#comment-13383792 ] Tibor Zim?nyi commented on DROOLS-1494: --------------------------------------- I tried your PR and the results are similar to yours. So I agree that this should be closed. I created a long term JIRA for better enhancement here: https://issues.jboss.org/browse/DROOLS-1495. > Problems with parallel agenda > ----------------------------- > > Key: DROOLS-1494 > URL: https://issues.jboss.org/browse/DROOLS-1494 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zim?nyi > Assignee: Mario Fusco > Labels: reported-by-qe > Fix For: 7.0.0.Beta8 > > > From doc [1] there can be seen that four benchmarks show problems when run with parallel agenda enabled. > Benchmarks _AdvOperators3ExpertBenchmark_ and _RetractFactsFromWmExpertBenchmark_ > falled back to single threaded agenda although they doesn't use features that aren't supported with parallel agenda (e.g. like salience). > Benchmarks StartsStartedbyFusionBenchmark and UpdateFactsInWmExpertBenchmark shows no gain when using parallel agenda although they contain more partitions. > I created runners for debugging here [2], so the benchmarks can be debugged outside of JMH. They are part of master branch in kie-benchmarks, so just pull of new changes is sufficient to get them. > [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1hp5lLcmox_NFEUsqNSNZBW2XvkrJWgj0LtEiVvbsCYU/edit?usp=sharing > [2] https://github.com/kiegroup/kie-benchmarks/commit/887f758931b02d096f1e870a3145119db315e1af -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 09:52:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Fri, 24 Mar 2017 09:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2563) Missing failure description for incorrect module in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2563: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Missing failure description for incorrect module in Elytron dir-context > ----------------------------------------------------------------------- > > Key: WFCORE-2563 > URL: https://issues.jboss.org/browse/WFCORE-2563 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Labels: user_experience > > In case when {{module}} attribute from Elytron {{dir-context}} includes module which does not exist, then insufficient failure description is provided - it only prints name of given module. It should rather inform that given module does not exist. > See: > {code} > /subsystem=elytron/dir-context=someDirContext:add(url=localhost,module=wrong.module) > { > "outcome" => "failed", > "failure-description" => "wrong.module", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 10:01:00 2017 From: issues at jboss.org (Martin Stefanko (JIRA)) Date: Fri, 24 Mar 2017 10:01:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI @Stereotype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko reassigned WFLY-8136: ------------------------------------- Assignee: Martin Stefanko (was: Alessio Soldano) > allow JAX-RS @Produces in CDI @Stereotype > ----------------------------------------- > > Key: WFLY-8136 > URL: https://issues.jboss.org/browse/WFLY-8136 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, REST > Affects Versions: 9.0.1.Final > Environment: Windows 7, JDK 1.8.0_60 > Reporter: Andreas Klemp > Assignee: Martin Stefanko > > A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used. > {code} > @Stereotype > @Produces(MediaType.APPLICATION_JSON) > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface RestService { > } > @Path("/some") > @RestService > public class SomeRestService { > @GET > @Path("/") > public Response getSome() { > return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build(); > } > } > {code} > Using the following dependencies in Gradle project. > {noformat} > providedCompile( > [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'], > [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'], > [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4'] > ) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 10:25:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 10:25:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2576) Operation failure descriptions following service start failures are overly noisy. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9887 to WFCORE-2576: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2576 (was: JBEAP-9887) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) > Operation failure descriptions following service start failures are overly noisy. > --------------------------------------------------------------------------------- > > Key: WFCORE-2576 > URL: https://issues.jboss.org/browse/WFCORE-2576 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > An example failure from JBEAP-6887: > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store-client.cs_not_found_exception" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store-client.cs_not_found_exception: WFLYELY00004: Unable to start the service. > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09506: Cannot read credential storage file '/home/hsvabek/securityworkspace/VERIFICATION/2016_11_02_UX_testing/jboss-eap-7.1.0.DR7/standalone/data/cs/keystore-not_exists.jceks' for the store named 'cs_not_found_exception' > Caused by: java.io.FileNotFoundException: /home/hsvabek/securityworkspace/VERIFICATION/2016_11_02_UX_testing/jboss-eap-7.1.0.DR7/standalone/data/cs/keystore-not_exists.jceks (No such file or directory)"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.cs_not_found_exception"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > There is no requirement not to show an exception or stack trace snippet. IMHO it's the best part of the message. And it's not feasible to show nothing else, as there are a number of layers in between. > But, this can certainly be improved, which is what this issue is about: > 1) "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > This is just noise. I'm quite certain this is already fixed and verified in a different issue though. Reproducing this against current code doesn't show this bit any longer. > 2) "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store-client.cs_not_found_exception: " > This is superfluous, since it follows ""WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store-client.cs_not_found_exception"" which says the same thing. This can go. > 3) ""WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.cs_not_found_exception"]" > Seems redundant since the only non-installed service listed is the one already reported as failed. This I'm not certain I'll fix as doing so may introduce some other issue. But I'll have a look. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 10:31:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Fri, 24 Mar 2017 10:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8448) Upgrade JBoss Metadata from 10.0.0.Final to 10.0.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf moved JBEAP-9888 to WFLY-8448: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8448 (was: JBEAP-9888) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Target Release: (was: 7.1.0.GA) > Upgrade JBoss Metadata from 10.0.0.Final to 10.0.1.Final > -------------------------------------------------------- > > Key: WFLY-8448 > URL: https://issues.jboss.org/browse/WFLY-8448 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 10:43:00 2017 From: issues at jboss.org (Fedor Gavrilov (JIRA)) Date: Fri, 24 Mar 2017 10:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8449) EJB contextData not sent back to client in response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fedor Gavrilov moved JBEAP-9889 to WFLY-8449: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8449 (was: JBEAP-9889) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Fix Version/s: (was: 7.1.0.GA) > EJB contextData not sent back to client in response > --------------------------------------------------- > > Key: WFLY-8449 > URL: https://issues.jboss.org/browse/WFLY-8449 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > Labels: ejb > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 10:50:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Fri, 24 Mar 2017 10:50:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1027) CS tool, Parameter --salt requires --iteration and vice versa In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned ELY-1027: ---------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > CS tool, Parameter --salt requires --iteration and vice versa > ------------------------------------------------------------- > > Key: ELY-1027 > URL: https://issues.jboss.org/browse/ELY-1027 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > If I use only one parameter from --salt or --iteration then this one is ignored and result password is in clear text. > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt="abcdefgh" > {code} > Result of this command is: > {code} > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > *There is expected error.* > Please add there this constraint: parameter --salt requires --iteration and vice versa -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 10:54:00 2017 From: issues at jboss.org (Jiri Petrlik (JIRA)) Date: Fri, 24 Mar 2017 10:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1496) Parallel agenda freezes when running fireUntilHalt on multiple KieSessions In-Reply-To: References: Message-ID: Jiri Petrlik created DROOLS-1496: ------------------------------------ Summary: Parallel agenda freezes when running fireUntilHalt on multiple KieSessions Key: DROOLS-1496 URL: https://issues.jboss.org/browse/DROOLS-1496 Project: Drools Issue Type: Bug Components: core engine Reporter: Jiri Petrlik Assignee: Mario Fusco Parallel agenda freezes when running in multiple KieSessions. Reproducer is in "testMultipleParallelKieSessionsFireUntilHalt" test from https://github.com/kiegroup/drools/pull/1164/commits/b3d8edee350b4e05101f9ebb1ee96443a449d78f Reproducer does the following steps: # Create kie base. # Run 5 separate threads. # Each thread creates its own kie session with parallel agenda enabled. # Run fire until halt on its own kie session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:03:01 2017 From: issues at jboss.org (Fedor Gavrilov (JIRA)) Date: Fri, 24 Mar 2017 11:03:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fedor Gavrilov closed WFLY-1805. -------------------------------- Resolution: Duplicate Issue dup https://issues.jboss.org/browse/WFLY-8449 > It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1805 > URL: https://issues.jboss.org/browse/WFLY-1805 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Labels: ejb > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:08:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 24 Mar 2017 11:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383917#comment-13383917 ] Bela Ban commented on JGRP-2162: -------------------------------- >From [~pruivo]: I'm experiencing some issue with multicast message and TCP_NIO2 in my laptop. I was looping OrphanTransactionsCleanupTest with trace enabled to find out what is going on and it seems that TCP_NIO2 is not working properly with multicast message. It seems that the first message sent to a node (where it has to establish the connection) is not sent at all. However, it is successful retransmitted ~16 sec after it was initial sent (in the meanwhile, the operation has timed-out). There is a description with parts the of the log below (sorry for the long email). The full log file is in attachment. The config use is [1]. Has anyone seen something similar? @Bela, Is there any issue with the config? Can we make the retransmission to happen sooner? > Failed to send broadcast when opening the connection > ---------------------------------------------------- > > Key: JGRP-2162 > URL: https://issues.jboss.org/browse/JGRP-2162 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 4.0.2 > > Attachments: TcpNio2McastTest.java > > > IRC discussion: > {quote} > bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. > rvansa: reproducible? > bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" > bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be > rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit > rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough > bela_: I don't think it should go over the limit > bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting > bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message > {quote} > I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): > {code:xml} > > {code} > This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore). > Note that increasing the timeout in request options does not help. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:09:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 24 Mar 2017 11:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2162: --------------------------- Attachment: infinispan_2.log.gz > Failed to send broadcast when opening the connection > ---------------------------------------------------- > > Key: JGRP-2162 > URL: https://issues.jboss.org/browse/JGRP-2162 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 4.0.2 > > Attachments: TcpNio2McastTest.java, infinispan_2.log.gz > > > IRC discussion: > {quote} > bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side. > rvansa: reproducible? > bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending" > bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be > rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit > rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don?t wait long enough > bela_: I don't think it should go over the limit > bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting > bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message > {quote} > I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]): > {code:xml} > > {code} > This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore). > Note that increasing the timeout in request options does not help. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:14:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 24 Mar 2017 11:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2166) Attributes should also be set via environment variables In-Reply-To: References: Message-ID: Bela Ban created JGRP-2166: ------------------------------ Summary: Attributes should also be set via environment variables Key: JGRP-2166 URL: https://issues.jboss.org/browse/JGRP-2166 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0.2 Currently, attributes such as {{mcast_port=${my.mcast_port:7500}}} are set to 7500 by default. If there is a system property {{my.mcast_port}}, then it will override the port. We should also look for environment values; the precedence would be * If there is a system property, use it * If not, if there is an environment variable, use it // this is new * Else use the configured value (e.g. 7500) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:15:01 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 24 Mar 2017 11:15:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2166) Attributes should also be set via environment variables In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-2166: --------------------------- Description: Currently, an attribute such as {{mcast_port=$\{my.mcast_port:7500\}}} is set to 7500 by default. If there is a system property {{my.mcast_port}}, it will override the port. We should also look for environment values; the precedence would be * If there is a system property, use it * If not, if there is an environment variable, use it // this is new * Else use the configured value (e.g. 7500) was: Currently, attributes such as {{mcast_port=${my.mcast_port:7500}}} are set to 7500 by default. If there is a system property {{my.mcast_port}}, then it will override the port. We should also look for environment values; the precedence would be * If there is a system property, use it * If not, if there is an environment variable, use it // this is new * Else use the configured value (e.g. 7500) > Attributes should also be set via environment variables > ------------------------------------------------------- > > Key: JGRP-2166 > URL: https://issues.jboss.org/browse/JGRP-2166 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.2 > > > Currently, an attribute such as {{mcast_port=$\{my.mcast_port:7500\}}} is set to 7500 by default. If there is a system property {{my.mcast_port}}, it will override the port. > We should also look for environment values; the precedence would be > * If there is a system property, use it > * If not, if there is an environment variable, use it // this is new > * Else use the configured value (e.g. 7500) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:34:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 24 Mar 2017 11:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8381) EjbInWarLibPackagingTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned WFLY-8381: ---------------------------------- Assignee: Martin Kouba > EjbInWarLibPackagingTestCase fails with security manager > -------------------------------------------------------- > > Key: WFLY-8381 > URL: https://issues.jboss.org/browse/WFLY-8381 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Martin Kouba > > *org.jboss.as.test.integration.weld.ejb.packaging.warlib.EjbInWarLibPackagingTestCase#testEjbInWarLibResolvedCorrectly* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=EjbInWarLibPackagingTestCase -Dsecurity.manager}} > {code} > 14:44:19,372 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-1) WFLYEJB0034: EJB Invocation failed on component WarLibEjb for method public abstract org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb org.jboss.as.test.integration.weld.ejb.packaging.warlib.WarLibInterface.getEjb(): javax.ejb.EJBException: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) > at org.jboss.as.test.integration.weld.ejb.packaging.warlib.WarLibInterface$$$view2.getEjb(Unknown Source) > at org.jboss.as.test.integration.weld.ejb.packaging.warlib.EjbInWarLibPackagingTestCase.testEjbInWarLibResolvedCorrectly(EjbInWarLibPackagingTestCase.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319) > at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162) > at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141) > at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) > at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) > at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:64) > at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:61) > at org.jboss.as.ejb3.pool.AbstractPool.create(AbstractPool.java:56) > at org.jboss.as.ejb3.pool.strictmax.StrictMaxPool.get(StrictMaxPool.java:124) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > ... 179 more > Caused by: javax.ejb.EJBException: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb with qualifiers [@Any @Default]; local interfaces are [OtherEjb] > Proxy: class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb$Proxy$_$$_Weld$EnterpriseProxy$ > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:344) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > ... 188 more > Caused by: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb with qualifiers [@Any @Default]; local interfaces are [OtherEjb] > Proxy: class org.jboss.as.test.integration.weld.ejb.packaging.warlib.OtherEjb$Proxy$_$$_Weld$EnterpriseProxy$ > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:72) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:758) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:858) > at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) > at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:150) > at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:75) > at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) > at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112) > at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.produce(SessionBeanInjectionTarget.java:126) > at org.jboss.as.weld.injection.WeldInjectionContext.produce(WeldInjectionContext.java:46) > at org.jboss.as.weld.injection.WeldConstructionStartInterceptor.processInvocation(WeldConstructionStartInterceptor.java:37) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:26) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > ... 201 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/CdiInterceptorPackaging.war/WEB-INF/lib/lib.jar )" of "ModuleClassLoader for Module "deployment.CdiInterceptorPackaging.war" 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.Class.checkMemberAccess(Class.java:200) > at java.lang.Class.getDeclaredConstructors(Class.java:719) > at org.jboss.weld.util.reflection.DeclaredMemberIndexer.getDeclaredConstructors(DeclaredMemberIndexer.java:146) > at org.jboss.weld.util.reflection.DeclaredMemberIndexer.getIndexForConstructor(DeclaredMemberIndexer.java:93) > at org.jboss.weld.serialization.ConstructorHolder.(ConstructorHolder.java:46) > at org.jboss.weld.serialization.ConstructorHolder.of(ConstructorHolder.java:37) > at org.jboss.weld.serialization.InjectionPointHolder$ConstructorParameterInjectionPointIdentifier.(InjectionPointHolder.java:220) > at org.jboss.weld.serialization.InjectionPointHolder.(InjectionPointHolder.java:65) > at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:51) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:78) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > ... 227 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 11:35:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 24 Mar 2017 11:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8378) BootstrapBeanDeploymentArchiveTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned WFLY-8378: ---------------------------------- Assignee: Martin Kouba > BootstrapBeanDeploymentArchiveTestCase fails with security manager > ------------------------------------------------------------------ > > Key: WFLY-8378 > URL: https://issues.jboss.org/browse/WFLY-8378 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Martin Kouba > > *org.wildfly.test.integration.weld.beanarchives.BootstrapBeanDeploymentArchiveTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=BootstrapBeanDeploymentArchiveTestCase -Dsecurity.manager}} > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."17004ed3-67af-464b-832a-56e1a1fe7f3d.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."17004ed3-67af-464b-832a-56e1a1fe7f3d.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.event.ObserverException > at java.lang.J9VMInternals.newInstanceImpl(Native Method) > at java.lang.Class.newInstance(Class.java:1899) > at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) > at java.security.AccessController.doPrivileged(AccessController.java:650) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:96) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) > at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) > at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:62) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:431) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.lang.ExceptionInInitializerError > at java.lang.J9VMInternals.ensureError(J9VMInternals.java:141) > at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:130) > at org.wildfly.test.integration.weld.beanarchives.TestExtension.beforeBeanDiscovery(TestExtension.java:49) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > ... 21 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/17004ed3-67af-464b-832a-56e1a1fe7f3d.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.17004ed3-67af-464b-832a-56e1a1fe7f3d.war" 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.Class.checkMemberAccess(Class.java:200) > at java.lang.Class.getDeclaredMethods(Class.java:992) > at javax.enterprise.util.AnnotationLiteral.getMembers(AnnotationLiteral.java:78) > at javax.enterprise.util.AnnotationLiteral.(AnnotationLiteral.java:69) > at org.wildfly.test.integration.weld.beanarchives.Alpha$Literal.(Alpha.java:39) > at org.wildfly.test.integration.weld.beanarchives.Alpha$Literal.(Alpha.java:42) > ... 27 more > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:62) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:431) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 13:17:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Fri, 24 Mar 2017 13:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-323) Validate composite operation steps just before executing them In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384031#comment-13384031 ] Radoslav Husar commented on WFCORE-323: --------------------------------------- Also note that extension :remove within a batch does not work: {noformat} [standalone at localhost:10090 /] batch [standalone at localhost:10090 / #] /subsystem=mail:remove [standalone at localhost:10090 / #] /extension=org.jboss.as.mail:remove [standalone at localhost:10090 / #] run-batch The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed: Step: step-1 Operation: /subsystem=mail:remove Failure: WFLYCTL0158: Operation handler failed: java.lang.NullPointerException {noformat} server log {noformat} 18:05:27,501 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("remove") failed - address: ([ ("subsystem" => "mail"), ("mail-session" => "default") ]): java.lang.NullPointerException at org.jboss.as.controller.CapabilityRegistry.getCapabilitiesForAddress(CapabilityRegistry.java:422) at org.jboss.as.controller.CapabilityRegistry.capabilityReloadRequired(CapabilityRegistry.java:399) at org.jboss.as.controller.AbstractOperationContext.reloadRequired(AbstractOperationContext.java:1121) at org.jboss.as.controller.ServiceRemoveStepHandler.performRuntime(ServiceRemoveStepHandler.java:124) at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:82) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {noformat} > Validate composite operation steps just before executing them > ------------------------------------------------------------- > > Key: WFCORE-323 > URL: https://issues.jboss.org/browse/WFCORE-323 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Labels: EAP > > Say we have a composite operation with 2 steps: > 1) /extension=org.jboss.as.messaging:add > 2) /subsystem=messaging:add > This will fail: > Failed to execute batch: JBAS014739: No handler for add at address > [("subsystem" => "messaging")] > This fails because at the time of validation the /subsystem=messaging:add is not valid. > To illustrate, the execution order is > Validate 1-2 > 1 > 2 > A possible solution is to convert this to the following: > V1 > 1 > V2 (works now because 1 has registered the subsystem API) > 2 > I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 13:35:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 24 Mar 2017 13:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1497) Implement RuleEventListener In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1497: ----------------------------------- Summary: Implement RuleEventListener Key: DROOLS-1497 URL: https://issues.jboss.org/browse/DROOLS-1497 Project: Drools Issue Type: Feature Request Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco Implement a programmatic RuleEventListener with the lifecycle described in https://developer.jboss.org/wiki/RuleExecutionSemantics -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 13:36:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 24 Mar 2017 13:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1478) Call ActivationUnMatchListener also when a rule rematches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-1478. --------------------------------- Fix Version/s: 7.0.0.Beta8 Resolution: Out of Date Replaced by https://issues.jboss.org/browse/DROOLS-1497 > Call ActivationUnMatchListener also when a rule rematches > --------------------------------------------------------- > > Key: DROOLS-1478 > URL: https://issues.jboss.org/browse/DROOLS-1478 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta8 > > > ActivationUnMatchListener is part of kie-internal, so its *not public API*. > *ActivationUnMatchListener is only used by OptaPlanner* (probably): > jBPM and downstream drools module don't use it: > https://github.com/search?q=org%3Akiegroup+ActivationUnMatchListener&type=Code > Community users probably don't use it either, because no one mentions it on StackOverflow: > https://www.google.be/search?q=%2BActivationUnMatchListener+site:stackoverflow.com&* > ---- > The current behaviour of ActivationUnMatchListener is a pain because it doesn't unmatch if a RHS fires again, causing an imbalance. OptaPlanner works around this through a hack (which fails for PLANNER-761). > For example, given this rule > {code} > global int score = 0; > rule R > when > Wine(age < 10, $age : age) > then > score += $age; > addUnmatchListener(() -> score -= $age); > end > {code} > This works for a normal match and unmatch event: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 0; // GOOD > {code} > So events are like this: > {code} > RHS > unmatch > {code} > However if we have a rematch: > {code} > Wine w = new Wine(3); > insert(w); > fireAllRules(); => score = 7; > w.age = 4; > update(w); > fireAllRules(); => no unmatch triggers => score = 13; // BAD Should be 6. Unmatch should have triggered. > w.age = 50; > update(w); > fireAllRules(); => unmatch triggers => score = 7; // Should be 0. > {code} > Because the events are unbalanced: > {code} > RHS > RHS > unmatch > {code} > I'd argue that anyone using the ActivationUnMatchListener would want to the have balanced events. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 13:45:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 13:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2577) ModelOnlyResourceDefinition does not expose a constructor that takes a Parameters object. In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2577: ---------------------------------------- Summary: ModelOnlyResourceDefinition does not expose a constructor that takes a Parameters object. Key: WFCORE-2577 URL: https://issues.jboss.org/browse/WFCORE-2577 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Priority: Minor It's better to wire up resource definitions using Parameters so we should support it for this one too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 14:02:00 2017 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Fri, 24 Mar 2017 14:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1311) PDF asciidoc generation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384054#comment-13384054 ] Geoffrey De Smet commented on DROOLS-1311: ------------------------------------------ plugin upgraded, but waiting for mvn dir structure to be able to fix pdf > PDF asciidoc generation > ----------------------- > > Key: DROOLS-1311 > URL: https://issues.jboss.org/browse/DROOLS-1311 > Project: Drools > Issue Type: Feature Request > Components: docs > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > Using approach from optaplanner-docs in asciidoc -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 16:56:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 16:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2549) Elytron, unable to configure Kerberos authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2549: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 3.0.0.Beta10) > Elytron, unable to configure Kerberos authentication > ---------------------------------------------------- > > Key: WFCORE-2549 > URL: https://issues.jboss.org/browse/WFCORE-2549 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta11 > > > *User impact:* User can't configure kerberos authentication using Elytron > *Workaround:* There is no workaround > *Description:* > If I try command which worked previously I get error > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"]) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException", > "rolled-back" => true > } > {code} > In server.log there is this stacktrace > {code} > 15:00:53,476 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("kerberos-security-factory" => "a") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:103) > at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:503) > at org.wildfly.extension.elytron.KerberosSecurityFactoryDefinition$2.getValueSupplier(KerberosSecurityFactoryDefinition.java:168) > at org.wildfly.extension.elytron.TrivialAddHandler.performRuntime(TrivialAddHandler.java:77) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Adding optional {{options}} attribute makes command work again > {code} > [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=a:add(principal=HTTP/localhost at JBOSS.ORG, path=/somewhere, mechanism-oids=["1.2.840.113554.1.2.2","1.3.6.1.5.5.2"],options={a=b}) > {"outcome" => "success"} > {code} > But after reload, there is error in server log > {code} > 18:30:37,430 ERROR [org.jboss.as.controller] (Controller Boot Thread) > OPVDX001: Validation error in standalone.xml ----------------------------------- > | > | 365: > | 366: > | 367: > | ^^^^ 'mappers' isn't an allowed element here > | > | Elements allowed here are: > | audit-logging policy > | authentication-client providers > | credential-security-factories sasl > | credential-stores security-domains > | dir-contexts security-properties > | http security-realms > | mappers tls > | > | 368: > | 369: > | 370: > | > | 'mappers' is allowed in elements: > | - server > profile > {urn:wildfly:elytron:1.0}subsystem > | " > | > | The primary underlying error message was: > | > ParseError at [row,col]:[367,13] > | > Message: WFLYCTL0198: Unexpected element > | > '{urn:wildfly:elytron:1.0}mappers' encountered > | > |------------------------------------------------------------------------------- > 18:30:37,430 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:376) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337) > at java.lang.Thread.run(Thread.java:745) > 18:30:37,432 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > Attribute {{options}} is marked correctly optional in model. > {code} > "options" => { > "type" => OBJECT, > "description" => "The Krb5LoginModule additional options.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 17:42:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 24 Mar 2017 17:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1028) AuthenticationException should extend IOException In-Reply-To: References: Message-ID: David Lloyd created ELY-1028: -------------------------------- Summary: AuthenticationException should extend IOException Key: ELY-1028 URL: https://issues.jboss.org/browse/ELY-1028 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: David Lloyd Assignee: David Lloyd Remote authentications use I/O. AuthenticationException pertains solely to remote authentications. Therefore it (like SaslException and many others) should extend IOException, not GeneralSecurityException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 17:43:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 24 Mar 2017 17:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1027) CS tool, Parameter --salt requires --iteration and vice versa In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384122#comment-13384122 ] David Lloyd commented on ELY-1027: ---------------------------------- Some password types use only salt, and some use only iteration count. The algorithm should be probed for support of the corresponding algorithm parameters to determine which flags are required for the given password type. > CS tool, Parameter --salt requires --iteration and vice versa > ------------------------------------------------------------- > > Key: ELY-1027 > URL: https://issues.jboss.org/browse/ELY-1027 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > If I use only one parameter from --salt or --iteration then this one is ignored and result password is in clear text. > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt="abcdefgh" > {code} > Result of this command is: > {code} > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > *There is expected error.* > Please add there this constraint: parameter --salt requires --iteration and vice versa -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:33:00 2017 From: issues at jboss.org (Carlo de Wolf (JIRA)) Date: Fri, 24 Mar 2017 18:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8448) Upgrade JBoss Metadata from 10.0.0.Final to 10.0.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlo de Wolf updated WFLY-8448: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9855 > Upgrade JBoss Metadata from 10.0.0.Final to 10.0.1.Final > -------------------------------------------------------- > > Key: WFLY-8448 > URL: https://issues.jboss.org/browse/WFLY-8448 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:36:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Fri, 24 Mar 2017 18:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-74: ---------------------------------- Attachment: 30minutes-raw.txt.zip > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30mins-ago4.txt, 30mins-ago5.txt, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:02 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2574) Ensure wrap on server-ssl-context default to false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2574: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Ensure wrap on server-ssl-context default to false > -------------------------------------------------- > > Key: WFCORE-2574 > URL: https://issues.jboss.org/browse/WFCORE-2574 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:02 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2521) TLS between domain and host controllers does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2521: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > TLS between domain and host controllers does not work > ----------------------------------------------------- > > Key: WFCORE-2521 > URL: https://issues.jboss.org/browse/WFCORE-2521 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: domain-management, domain-mode, eap71_alpha, regression, ssl > Fix For: 3.0.0.Beta12 > > > This is regression against EAP 7.0 . Customers relying on this feature won't be able to migrate to EAP 7.1. > Working configuration of TLS between domain and host controller from EAP 7.0 (legacy) does not work on EAP 7.1 anymore. > In server log there is this error: > {code:title=server.log} > [Host Controller] Caused by: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL > [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$StartTls.handleEvent(ClientConnectionOpenListener.java:527) > [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$StartTls.handleEvent(ClientConnectionOpenListener.java:477) > [Host Controller] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > [Host Controller] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > [Host Controller] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > [Host Controller] at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > [Host Controller] at ...asynchronous invocation...(Unknown Source) > [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466) > [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:437) > [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:430) > [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:163) > [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119) > [Host Controller] ... 9 more > {code} > See attached server.log for context log. > Tests in wildfly-core covering this scenario are currently ignored: > * SSLMasterSlaveOneWayTestCase is ignored by WFCORE-1978 > * SSLMasterSlaveTwoWayTestCase is ignored by WFCORE-2068 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:02 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2528) Clean up testsuite Elytron registration -- VaultPasswordsInCLITestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2528: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Clean up testsuite Elytron registration -- VaultPasswordsInCLITestCase > ---------------------------------------------------------------------- > > Key: WFCORE-2528 > URL: https://issues.jboss.org/browse/WFCORE-2528 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > Leftover cleanup from WFCORE-1958 since VaultPasswordsInCLITestCase is not enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2438) Legacy Kerberos for management interface returns 500 instead of 401 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2438: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Legacy Kerberos for management interface returns 500 instead of 401 > ------------------------------------------------------------------- > > Key: WFCORE-2438 > URL: https://issues.jboss.org/browse/WFCORE-2438 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta12 > > > On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case. > Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages > {code:title=server.log} > 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2386: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta12 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > Error401 - Unauthorized > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > Error401 - Unauthorized > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2486) Legacy ldap realm returns 401 if LDAP is unreachable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2486: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Legacy ldap realm returns 401 if LDAP is unreachable > ---------------------------------------------------- > > Key: WFCORE-2486 > URL: https://issues.jboss.org/browse/WFCORE-2486 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > Contradics JBEAP-8125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2349: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. > --------------------------------------------------------------------------------- > > Key: WFCORE-2349 > URL: https://issues.jboss.org/browse/WFCORE-2349 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not validated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2317: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Nested attributes are not validated > ----------------------------------- > > Key: WFCORE-2317 > URL: https://issues.jboss.org/browse/WFCORE-2317 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha25 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 3.0.0.Beta12 > > > Attributes of type Object do not have their inner attributes validated for e.g. "requires" and "alternatives". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2497: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:03 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2267: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2267 > URL: https://issues.jboss.org/browse/WFCORE-2267 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > Only the Elytron realms are now used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2245: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > credential-reference capability-reference constraint > ---------------------------------------------------- > > Key: WFCORE-2245 > URL: https://issues.jboss.org/browse/WFCORE-2245 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Claudio Miranda > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > There attribute credential-reference is defined in many subsystems as below. Looks like the capability-reference constraint should be set in the "store" field of the value-type, therefore I request a review on this capability-constraint placement. > {code} > "credential-reference" => { > "type" => OBJECT, > "description" => "Credential (from Credential Store) to authenticate on data source", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.credential-store", > "access-constraints" => {"sensitive" => { > "credential" => {"type" => "core"}, > "data-source-security" => {"type" => "datasources"} > }}, > "value-type" => { > "store" => { > "type" => STRING, > "description" => "The name of the credential store holding the alias to credential", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "alias" => { > "type" => STRING, > "description" => "The alias which denotes stored secret or credential in the store", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "type" => { > "type" => STRING, > "description" => "The type of credential this reference is denoting", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "clear-text" => { > "type" => STRING, > "description" => "Secret specified using clear text (check credential store way of supplying credential/secrets to services)", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2136: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2101) Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2101: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2101 > URL: https://issues.jboss.org/browse/WFCORE-2101 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > i.e. a later AS release will start to enable mechs like SCRAM, client should work without additional configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2100: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:04 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2068: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2068 > URL: https://issues.jboss.org/browse/WFCORE-2068 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > The listed test case is failing during clean up with the following error: - > {noformat} > java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80) > {noformat} > The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1960: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta12 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1944: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2016: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Change sasl-authentication-factor for management auth works after reload, but not after server restart > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2016 > URL: https://issues.jboss.org/browse/WFCORE-2016 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > I can successfully configure a new sasl-authentication-factory and assign it to the management interface: > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"]) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper) > /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) > reload > {code} > after reload, i am forced to re-authenticate and it succeeds: > {code} > [standalone at localhost:9990 /] reload > Authenticating against security realm: exampleSaslRealm > Username: user1 > Password: > [standalone at localhost:9990 /] > {code} > Once i restart the server though and try to connect, i get a timeout: > {code} > $ ./jboss-cli.sh -c > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code} > It also fails if i force no local auth: > {code} > $ ./jboss-cli.sh -c --no-local-auth > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code}/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once migrated to Remoting 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1897: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Follow up WFCORE-296 once migrated to Remoting 5 > ------------------------------------------------ > > Key: WFCORE-1897 > URL: https://issues.jboss.org/browse/WFCORE-1897 > Project: WildFly Core > Issue Type: Task > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1649: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 3.0.0.Beta12 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1560: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh > -------------------------------------------------------------------------------- > > Key: WFCORE-1560 > URL: https://issues.jboss.org/browse/WFCORE-1560 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.8.Final > Environment: OS: CentOS 7.2 > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Wildfly-10.0.0-Final > Reporter: Michael Noack > Assignee: Ken Wills > Priority: Critical > Fix For: 3.0.0.Beta12 > > Attachments: JVM-DC.png, console-dc.log, host-controller.log, process-controller.log > > > When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am): > [root at dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)" > Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out > I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue. > Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:05 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1606: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta12 > > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta12 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta12 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron, domain-mode > Fix For: 3.0.0.Beta12 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta12 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-887: ------------------------------------ Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta12 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 24 18:43:06 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 24 Mar 2017 18:43:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call non-published management API operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Beta12 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 00:10:00 2017 From: issues at jboss.org (Eric B (JIRA)) Date: Sat, 25 Mar 2017 00:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1898) Ability to store HttpSession in a external store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384140#comment-13384140 ] Eric B commented on WFLY-1898: ------------------------------ [~swd847] Do you have an example of a custom SessionManager that I could look at? I'm trying to figure out how to setup/configure/use Redis as my persistence mechanism for sessions, but can't quite figure out how to create a SessionManager that would user Redis. Any help, examples would be appreciated. > Ability to store HttpSession in a external store > ------------------------------------------------ > > Key: WFLY-1898 > URL: https://issues.jboss.org/browse/WFLY-1898 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Adrian Mitev > Assignee: Stuart Douglas > > I would like to keep the http session in an external store like Redis. There is a post how to configure that with older JBoss AS versions - https://community.jboss.org/wiki/HAWebSessionsViaDatabasePersistence -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 04:21:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Sat, 25 Mar 2017 04:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istv?n T?th updated WFLY-8431: ------------------------------ Attachment: GetFactoryTestCase.java > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 04:25:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Sat, 25 Mar 2017 04:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384141#comment-13384141 ] Istv?n T?th commented on WFLY-8431: ----------------------------------- I have attached a test case for the getFactory race. 1. Build the attached servlet into into a war (no config needed) 2. Deploy to a wildfly instance 3. restart wildfly instance 4. Access the servlet All displayed objects should be the same, but they are not. The bug only triggers on the first access, and sometimes takes a few restarts to trigger. > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 05:40:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sat, 25 Mar 2017 05:40:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2497: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 (was: 3.0.0.Beta12) > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 05:42:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sat, 25 Mar 2017 05:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384151#comment-13384151 ] Darran Lofthouse commented on WFCORE-2497: ------------------------------------------ Due to other commitments this is going to be postponed to 4 anyway so hopefully we can consider both at the same time. > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 06:07:00 2017 From: issues at jboss.org (=?UTF-8?Q?Istv=C3=A1n_T=C3=B3th_=28JIRA=29?=) Date: Sat, 25 Mar 2017 06:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384154#comment-13384154 ] Istv?n T?th commented on WFLY-8431: ----------------------------------- I have sent a PR for the JBossAuthConfigFactory problem as well. https://github.com/picketbox/picketbox/pull/68 > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: Istv?n T?th > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 08:43:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sat, 25 Mar 2017 08:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1029) Support clients that provide an optional CallbackHandler In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1029: ------------------------------------- Summary: Support clients that provide an optional CallbackHandler Key: ELY-1029 URL: https://issues.jboss.org/browse/ELY-1029 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 1.1.0.Beta34 Clients such as the WildFly CLI provide a CallbackHandler implementation in case it is needed and not as a sign that it must be used, i.e. the desired outcome is that if the information required can be obtained from the configuration then authentication proceeds without interaction with the end user. Neither the CLI or the end user should be required to be fully aware of the underlying security configuration. This is similar to web browser HTTP authentication where there is only an interaction with the user if actually required. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 09:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sat, 25 Mar 2017 09:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1030: ------------------------------------- Summary: Move TokenSecurityRealm to org.wildfly.security.auth.realm package Key: ELY-1030 URL: https://issues.jboss.org/browse/ELY-1030 Project: WildFly Elytron Issue Type: Enhancement Components: Realms Reporter: Darran Lofthouse Assignee: Pedro Igor Priority: Critical Fix For: 1.1.0.Beta34 The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 09:15:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sat, 25 Mar 2017 09:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384159#comment-13384159 ] Darran Lofthouse commented on ELY-1030: --------------------------------------- [~pcraveiro] Could you please take a look at this one? As the realm is simple I am not sure it required it's own package. > Move TokenSecurityRealm to org.wildfly.security.auth.realm package > ------------------------------------------------------------------ > > Key: ELY-1030 > URL: https://issues.jboss.org/browse/ELY-1030 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta34 > > > The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 10:18:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sat, 25 Mar 2017 10:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2340) Expose the management executor via a capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2340: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2213 > Expose the management executor via a capability > ----------------------------------------------- > > Key: WFCORE-2340 > URL: https://issues.jboss.org/browse/WFCORE-2340 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta12 > > > The ServerService and HostControllerService both expose an ExecutorService that, among other things, extensions can use for async work like blocking tasks in MSC Service start/stop calls. This should be available as a capability instead of requiring extensions to hard code service names from the server and host-controller modules. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 25 10:25:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Sat, 25 Mar 2017 10:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1031) Make the CredentialStore class final In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1031: ------------------------------------- Summary: Make the CredentialStore class final Key: ELY-1031 URL: https://issues.jboss.org/browse/ELY-1031 Project: WildFly Elytron Issue Type: Enhancement Components: Credential Store Reporter: Darran Lofthouse Assignee: Peter Skopek Priority: Critical Fix For: 1.1.0.Beta34 Unless there is a reason this has not already be done the class should probably be made final to be sure extension is not possible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 26 14:40:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Sun, 26 Mar 2017 14:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2578) Add ability to configure bind address for outbound XNIO connections In-Reply-To: References: Message-ID: David Lloyd created WFCORE-2578: ----------------------------------- Summary: Add ability to configure bind address for outbound XNIO connections Key: WFCORE-2578 URL: https://issues.jboss.org/browse/WFCORE-2578 Project: WildFly Core Issue Type: Enhancement Components: IO Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 00:49:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 00:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) 1st baseline In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-47: ---------------------------------- Summary: 1st baseline (was: Perform and document a small load test run) > 1st baseline > ------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 00:54:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 00:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-73: ---------------------------------- Description: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods- 239 promgen (prometheus generator) - verify metrics definition count - verify metrics data was: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - how many pods - verify metrics definition count - verify metrics data > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - -how many pods- 239 promgen (prometheus generator) > - verify metrics definition count > - verify metrics data -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 00:55:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 00:55:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-73: ---------------------------------- Description: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods- 239 promgen pods (prometheus generator) - verify metrics definition count - verify metrics data was: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods- 239 promgen (prometheus generator) - verify metrics definition count - verify metrics data > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - -how many pods- 239 promgen pods (prometheus generator) > - verify metrics definition count > - verify metrics data -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 00:56:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 00:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-73: ---------------------------------- Description: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods- 239 promgen pods (prometheus generator) - verify metrics definition count - verify metrics data Cluster info: OSE 3.5 - Master - - was: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods- 239 promgen pods (prometheus generator) - verify metrics definition count - verify metrics data > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - -how many pods- 239 promgen pods (prometheus generator) > - verify metrics definition count > - verify metrics data > Cluster info: OSE 3.5 > - Master > - - -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 00:58:03 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 00:58:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-73: ---------------------------------- Description: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - how many pods? - verify metrics definition count - verify metrics data Cluster info: OSE 3.5 - Master, infra node 46G RAM -- metrics, heapster, HOSA - Regular node 64G RAM -- 239 promgen pods (prometheus generator) + HOSA pod was: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods- 239 promgen pods (prometheus generator) - verify metrics definition count - verify metrics data Cluster info: OSE 3.5 - Master - - > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - how many pods? > - verify metrics definition count > - verify metrics data > Cluster info: OSE 3.5 > - Master, infra node 46G RAM > -- metrics, heapster, HOSA > - Regular node 64G RAM > -- 239 promgen pods (prometheus generator) + HOSA pod -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:00:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:00:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-73: ---------------------------------- Description: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - -how many pods?- 240 pods - verify custom metrics definition count - 2 per pod - verify metrics data - 30s interval, 2 per minute, 60 per 30 minutes Cluster info: OSE 3.5 - Master, infra node 46G RAM -- metrics, heapster, HOSA, 30s collection internal - Regular node 64G RAM -- 239 promgen pods (prometheus generator) + HOSA pod was: Use cluster2 (JON BC hardware) for a larger set up than OS1. - Rebuild cluster. Both master and node are on bare metal - 30 metrics per pod - how many pods? - verify metrics definition count - verify metrics data Cluster info: OSE 3.5 - Master, infra node 46G RAM -- metrics, heapster, HOSA - Regular node 64G RAM -- 239 promgen pods (prometheus generator) + HOSA pod > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - -how many pods?- 240 pods > - verify custom metrics definition count - 2 per pod > - verify metrics data - 30s interval, 2 per minute, 60 per 30 minutes > Cluster info: OSE 3.5 > - Master, infra node 46G RAM > -- metrics, heapster, HOSA, 30s collection internal > - Regular node 64G RAM > -- 239 promgen pods (prometheus generator) + HOSA pod -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:00:40 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:00:40 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381234#comment-13381234 ] viet nguyen edited comment on HAWKULARQE-73 at 3/27/17 1:00 AM: ---------------------------------------------------------------- master/node1: https://b16.jonqe.lab.eng.bos.redhat.com:8443/console node2: b20.jonqe.lab.eng.bos.redhat.com was (Author: vietn): master/node1: https://b16.jonqe.lab.eng.bos.redhat.com:8443/console node2: b20.jonqe.lab.eng.bos.redhat.com:8443/console > Rebuild internal cluster 2 > --------------------------- > > Key: HAWKULARQE-73 > URL: https://issues.jboss.org/browse/HAWKULARQE-73 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > Use cluster2 (JON BC hardware) for a larger set up than OS1. > - Rebuild cluster. Both master and node are on bare metal > - 30 metrics per pod > - -how many pods?- 240 pods > - verify custom metrics definition count - 2 per pod > - verify metrics data - 30s interval, 2 per minute, 60 per 30 minutes > Cluster info: OSE 3.5 > - Master, infra node 46G RAM > -- metrics, heapster, HOSA, 30s collection internal > - Regular node 64G RAM > -- 239 promgen pods (prometheus generator) + HOSA pod -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:04:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-74: ---------------------------------- Attachment: (was: 30mins-ago4.txt) > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:04:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-74: ---------------------------------- Attachment: (was: 30mins-ago5.txt) > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:13:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:13:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen edited comment on HAWKULARQE-74 at 3/27/17 1:12 AM: ---------------------------------------------------------------- I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} was (Author: vietn): I hit a hard limit at 239 pods on the node !239pods.png|thumbnail! {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:22:03 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:22:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen edited comment on HAWKULARQE-74 at 3/27/17 1:21 AM: ---------------------------------------------------------------- I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics in 30 minutes in the past. - 2 custom metrics / pod * 2/minutes * 30 minute = 60 metrics/30minutes was (Author: vietn): I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:25:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen edited comment on HAWKULARQE-74 at 3/27/17 1:24 AM: ---------------------------------------------------------------- I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - 2 raw metrics / minute * 30 minute = 60 metrics was (Author: vietn): I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics in 30 minutes in the past. - 2 custom metrics / pod * 2/minutes * 30 minute = 60 metrics/30minutes > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:27:04 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:27:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen edited comment on HAWKULARQE-74 at 3/27/17 1:26 AM: ---------------------------------------------------------------- I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - 2 raw metrics / minute * 30 minute = 60 metrics Observations: - Python client -> Metrics master endpoint on slow VPN connection causes exceptions in Metrics log [BZ 1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] was (Author: vietn): I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - 2 raw metrics / minute * 30 minute = 60 metrics > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:29:04 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:29:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen edited comment on HAWKULARQE-74 at 3/27/17 1:28 AM: ---------------------------------------------------------------- I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - Expecting 2 raw metrics / minute * 30 minute = 60 metrics / 30 minutes Observations: - Python client -> Metrics master endpoint on slow VPN connection causes exceptions in Metrics log [BZ 1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] - Few pods have less than 60 metrics. Need more investigation. was (Author: vietn): I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - 2 raw metrics / minute * 30 minute = 60 metrics Observations: - Python client -> Metrics master endpoint on slow VPN connection causes exceptions in Metrics log [BZ 1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 01:34:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Mon, 27 Mar 2017 01:34:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13383138#comment-13383138 ] viet nguyen edited comment on HAWKULARQE-74 at 3/27/17 1:33 AM: ---------------------------------------------------------------- I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. Cluster info https://issues.jboss.org/browse/HAWKULARQE-73 {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - Expecting 2 raw metrics / minute * 30 minute = 60 metrics / 30 minutes Observations: - Python client -> Metrics master endpoint on slow VPN connection causes exceptions in Metrics log [BZ 1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] - Few pods have less than 60 metrics (see attachment). Need more investigation. was (Author: vietn): I hit a hard limit at 240 pods on the node !239pods.png|thumbnail! 239 test pods + 1 HOSA pod. {code} [root at b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} - HOSA collection interval 30seconds - Use [Hawkular Python client |https://github.com/vnugent/pyme]and iterate through each pod counting number of raw metrics captured in 30 minute-duration. - Expecting 2 raw metrics / minute * 30 minute = 60 metrics / 30 minutes Observations: - Python client -> Metrics master endpoint on slow VPN connection causes exceptions in Metrics log [BZ 1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436] - Few pods have less than 60 metrics. Need more investigation. > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 03:15:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Mon, 27 Mar 2017 03:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-31) CFME Tests: Adjust Datasource automation tests to 4.5 release. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384243#comment-13384243 ] Hayk Hovsepyan commented on HAWKULARQE-31: ------------------------------------------ PR sent https://github.com/ManageIQ/integration_tests/pull/4440 > CFME Tests: Adjust Datasource automation tests to 4.5 release. > -------------------------------------------------------------- > > Key: HAWKULARQE-31 > URL: https://issues.jboss.org/browse/HAWKULARQE-31 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 03:16:07 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Mon, 27 Mar 2017 03:16:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-40) XA Datasource creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384244#comment-13384244 ] Hayk Hovsepyan commented on HAWKULARQE-40: ------------------------------------------ PR sent https://github.com/ManageIQ/integration_tests/pull/4440 > XA Datasource creation > ---------------------- > > Key: HAWKULARQE-40 > URL: https://issues.jboss.org/browse/HAWKULARQE-40 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Manual testcases. > Automation testcases. > BZ should be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1383611 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 03:32:06 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 27 Mar 2017 03:32:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8450) Make org.wildfly.transaction.client module unsupported In-Reply-To: References: Message-ID: Ondra Chaloupka created WFLY-8450: ------------------------------------- Summary: Make org.wildfly.transaction.client module unsupported Key: WFLY-8450 URL: https://issues.jboss.org/browse/WFLY-8450 Project: WildFly Issue Type: Bug Components: Transactions Reporter: Ondra Chaloupka Assignee: Tom Jenkinson Priority: Blocker Per e-mail discussion with David, the {{org.wildfly.transaction.client}} module currently doesn't contain anything meant to be used by application developers directly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 03:33:06 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 27 Mar 2017 03:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8450) Make org.wildfly.transaction.client module unsupported In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384255#comment-13384255 ] Ondra Chaloupka commented on WFLY-8450: --------------------------------------- Per discussion between David and Honza the wfly txn client should be marked unsupported. > Make org.wildfly.transaction.client module unsupported > ------------------------------------------------------ > > Key: WFLY-8450 > URL: https://issues.jboss.org/browse/WFLY-8450 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > > Per e-mail discussion with David, the {{org.wildfly.transaction.client}} module currently doesn't contain anything meant to be used by application developers directly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 03:33:06 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 27 Mar 2017 03:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8450) Make org.wildfly.transaction.client module unsupported In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned WFLY-8450: ------------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Make org.wildfly.transaction.client module unsupported > ------------------------------------------------------ > > Key: WFLY-8450 > URL: https://issues.jboss.org/browse/WFLY-8450 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Per e-mail discussion with David, the {{org.wildfly.transaction.client}} module currently doesn't contain anything meant to be used by application developers directly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 03:58:08 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Mon, 27 Mar 2017 03:58:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1032) Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1032: --------------------------------- Summary: Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option. Key: ELY-1032 URL: https://issues.jboss.org/browse/ELY-1032 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Help output has limit 160 chars for line length and it leads to ugly line break in the middle of one option. Command {code} java -jar wildfly-elytron-tool.jar credential-store --help {code} has this output: {code} usage: java -jar wildfly-elytron-tool.jar credential-store -a | -e | -h | -r | -v [-c] [-f] [-i ] [-l ] [-p ] [-s ] [-t ] [-u ] [-x ] {code} I expect at least line break before "-s" option {code} usage: java -jar wildfly-elytron-tool.jar credential-store -a | -e | -h | -r | -v [-c] [-f] [-i ] [-l ] [-p ] [-s ] [-t ] [-u ] [-x ] {code} The best option would be some dynamic settings of line length -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 05:40:07 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 27 Mar 2017 05:40:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8451) org.wildfly.clustering.web.session.IdentifierExternalizerTestCase#toHex fails on JDK9 b162 In-Reply-To: References: Message-ID: Radoslav Husar created WFLY-8451: ------------------------------------ Summary: org.wildfly.clustering.web.session.IdentifierExternalizerTestCase#toHex fails on JDK9 b162 Key: WFLY-8451 URL: https://issues.jboss.org/browse/WFLY-8451 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar testHex(org.wildfly.clustering.web.session.IdentifierExternalizerTestCase) Time elapsed: 0.008 sec <<< ERROR! java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476) at org.wildfly.clustering.web.IdentifierExternalizer$3.writeObject(IdentifierExternalizer.java:74) at org.wildfly.clustering.web.IdentifierExternalizer$3.writeObject(IdentifierExternalizer.java:71) at org.wildfly.clustering.web.session.IdentifierExternalizerTestCase.test(IdentifierExternalizerTestCase.java:97) at org.wildfly.clustering.web.session.IdentifierExternalizerTestCase.testHex(IdentifierExternalizerTestCase.java:61) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 06:14:08 2017 From: issues at jboss.org (John Farrelly (JIRA)) Date: Mon, 27 Mar 2017 06:14:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8452) Management Interfaces stopping before server fully shutdown In-Reply-To: References: Message-ID: John Farrelly created WFLY-8452: ----------------------------------- Summary: Management Interfaces stopping before server fully shutdown Key: WFLY-8452 URL: https://issues.jboss.org/browse/WFLY-8452 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 10.1.0.Final Reporter: John Farrelly Assignee: Jason Greene In our product, we use jboss-cli.sh to monitor if WildFly is running ({{jboss-cli.sh -c --controller=${JBOSS_HOST}:${JBOSS_MANAGEMENT_PORT} "read-attribute server-state"}}). We've been using this mechanism to determine if JBoss/WildFly is running since JBoss 7.1.1.Final. What we are seeing in WildFly 10.1.0.Final is that WildFly shuts down the native interface before it has closed all other services. This means that some long-running business logic thread in WildFly can stop it from shutting down, but the native interface has already stopped, making it seem that WildFly has stopped. I can see that other services (such as undertow) stay up until the long running business logic thread has completed. This is a regression from JBoss AS 7.1.1, where the management interfaces would not stop while long running business logic was still executing. Here's the management section of my standalone.xml: {code:xml} {code} We use {{jboss-cli.sh}} to issue the shutdown command: {code} jboss-cli.sh -c --controller=${JBOSS_HOST}:${JBOSS_MANAGEMENT_PORT} --command=":shutdown" {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 06:32:05 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Mon, 27 Mar 2017 06:32:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384378#comment-13384378 ] Pedro Igor commented on ELY-1030: --------------------------------- I'm OK with this change. > Move TokenSecurityRealm to org.wildfly.security.auth.realm package > ------------------------------------------------------------------ > > Key: ELY-1030 > URL: https://issues.jboss.org/browse/ELY-1030 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta34 > > > The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 06:33:03 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 06:33:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8452) Management Interfaces stopping before server fully shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-8452. ----------------------------- Assignee: Stuart Douglas (was: Jason Greene) Resolution: Rejected This is not a regression in any way, it is a graceful shutdown in action. For your case, you should probably suspend server first and then shut it down. {{:suspend(timeout=)}} this way server will just finish serving all in-flight requests but stop accepting new ones. after that you can shutdown the server. you could also try with {{:shutdown(timeout=)}} but I don't know on top of my head if that would work in your scenario. > Management Interfaces stopping before server fully shutdown > ----------------------------------------------------------- > > Key: WFLY-8452 > URL: https://issues.jboss.org/browse/WFLY-8452 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.1.0.Final > Reporter: John Farrelly > Assignee: Stuart Douglas > > In our product, we use jboss-cli.sh to monitor if WildFly is running ({{jboss-cli.sh -c --controller=${JBOSS_HOST}:${JBOSS_MANAGEMENT_PORT} "read-attribute server-state"}}). We've been using this mechanism to determine if JBoss/WildFly is running since JBoss 7.1.1.Final. > What we are seeing in WildFly 10.1.0.Final is that WildFly shuts down the native interface before it has closed all other services. This means that some long-running business logic thread in WildFly can stop it from shutting down, but the native interface has already stopped, making it seem that WildFly has stopped. > I can see that other services (such as undertow) stay up until the long running business logic thread has completed. This is a regression from JBoss AS 7.1.1, where the management interfaces would not stop while long running business logic was still executing. > Here's the management section of my standalone.xml: > {code:xml} > > > > > > > > > > > > > > > > > > > > > > > {code} > > We use {{jboss-cli.sh}} to issue the shutdown command: > {code} > jboss-cli.sh -c --controller=${JBOSS_HOST}:${JBOSS_MANAGEMENT_PORT} --command=":shutdown" > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 06:47:07 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 27 Mar 2017 06:47:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2579) Rename WildFly Elytron Subsystem to wildfly-elytron-integration In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2579: ---------------------------------------- Summary: Rename WildFly Elytron Subsystem to wildfly-elytron-integration Key: WFCORE-2579 URL: https://issues.jboss.org/browse/WFCORE-2579 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 06:47:17 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 27 Mar 2017 06:47:17 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2580) Rename WildFly Elytron Subsystem to wildfly-elytron-integration In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2580: ---------------------------------------- Summary: Rename WildFly Elytron Subsystem to wildfly-elytron-integration Key: WFCORE-2580 URL: https://issues.jboss.org/browse/WFCORE-2580 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 06:48:13 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 27 Mar 2017 06:48:13 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8453) Rename WildFly Elytron Subsystem to wildfly-elytron-integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFCORE-2580 to WFLY-8453: ------------------------------------------------ Project: WildFly (was: WildFly Core) Key: WFLY-8453 (was: WFCORE-2580) Component/s: Security (was: Security) Fix Version/s: 11.0.0.Alpha1 (was: 3.0.0.Beta12) > Rename WildFly Elytron Subsystem to wildfly-elytron-integration > --------------------------------------------------------------- > > Key: WFLY-8453 > URL: https://issues.jboss.org/browse/WFLY-8453 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 07:11:04 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Mon, 27 Mar 2017 07:11:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1033) CS tool, Usage of --help option with other options must display help rather than error message.. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1033: --------------------------------- Summary: CS tool, Usage of --help option with other options must display help rather than error message.. Key: ELY-1033 URL: https://issues.jboss.org/browse/ELY-1033 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Help option have to have priority over other options. When I use --help option with other options I want to see help rather than error message.. {code} [hsvabek at dhcp-10-40-5-145 bin]$ java -jar wildfly-elytron-tool.jar mask --help -i 230 -s 12345678 -x secret_password The option 'x' was specified but an option from this group has already been selected: 'h' {code} Same for *credential-store* command. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 07:27:03 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Mon, 27 Mar 2017 07:27:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman reopened WFLY-8032: -------------------------------- Assignee: Tomas Hofman (was: Stefano Maestri) Reopening due to regression: https://issues.jboss.org/browse/JBEAP-9730?focusedCommentId=13382943&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13382943 > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8032 > URL: https://issues.jboss.org/browse/WFLY-8032 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 07:48:40 2017 From: issues at jboss.org (Prachi Yadav (JIRA)) Date: Mon, 27 Mar 2017 07:48:40 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384445#comment-13384445 ] Prachi Yadav commented on HAWKULARQE-37: ---------------------------------------- Working on Automation Test > Server Group Deployment > ----------------------- > > Key: HAWKULARQE-37 > URL: https://issues.jboss.org/browse/HAWKULARQE-37 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:08:06 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:08:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3289) Intermittent failures in PassworkMaskingTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-3289. ----------------------------- Resolution: Out of Date > Intermittent failures in PassworkMaskingTestCase > ------------------------------------------------ > > Key: WFLY-3289 > URL: https://issues.jboss.org/browse/WFLY-3289 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Affects Versions: 8.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Peter Skopek > > PasswordMaskingTestCase fails intermittently. See, for example, http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=14404&buildTypeId=WFPR > The log shows this: > 05:55:56,496 ERROR [org.jboss.as.arquillian.container.ServerSetupObserver] (main) Setup task failed during setup. Offending class 'org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingTestCase$PasswordMaskingTestCaseSetup at 4b584d': java.lang.RuntimeException: Problem creating VaultSession: > at org.jboss.as.test.integration.security.common.VaultHandler.(VaultHandler.java:168) > at org.jboss.as.test.integration.security.common.VaultHandler.(VaultHandler.java:180) > at org.jboss.as.test.integration.security.common.VaultHandler.(VaultHandler.java:188) > at org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingTestCase$PasswordMaskingTestCaseSetup.setup(PasswordMaskingTestCase.java:91) > at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:116) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > . . . > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.Exception: Exception encountered: > at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:173) > at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:191) > at org.jboss.as.test.integration.security.common.VaultHandler.(VaultHandler.java:166) > ... 103 more > Caused by: org.jboss.security.vault.SecurityVaultException: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) > at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:170) > ... 105 more > Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:750) > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676) > at com.sun.crypto.provider.PBECipherCore.doFinal(PBECipherCore.java:422) > at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(PBEWithMD5AndDESCipher.java:316) > at javax.crypto.Cipher.doFinal(Cipher.java:2087) > at org.jboss.security.plugins.PBEUtils.decode(PBEUtils.java:72) > at org.jboss.security.plugins.PBEUtils.decode64(PBEUtils.java:81) > at org.picketbox.plugins.vault.PicketBoxSecurityVault.decode(PicketBoxSecurityVault.java:362) > at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:339) > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) > ... 106 more > Per discussion at http://lists.jboss.org/pipermail/wildfly-dev/2014-April/002064.html I am going to @Ignore this test and it is subject to being removed 3 weeks after 8.1.0.Final if not corrected. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:11:09 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Mon, 27 Mar 2017 08:11:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2393) Elytron expects certificate in PEM format as user input In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Igor updated WFCORE-2393: ------------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly-core/pull/66, https://github.com/wildfly-security-incubator/wildfly-core/pull/100 (was: https://github.com/wildfly-security-incubator/wildfly-core/pull/66) > Elytron expects certificate in PEM format as user input > ------------------------------------------------------- > > Key: WFCORE-2393 > URL: https://issues.jboss.org/browse/WFCORE-2393 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Pedro Igor > Labels: user_experience > Fix For: 3.0.0.Beta9 > > > In {{/token-realm/public-key}} attribute there is certificate in PEM format expected, which I consider to be user un-friendly. > I wonder couldn't that be accomplished by leveraging key-store/trust-manager capability? > {code} > "public-key" => { > "type" => STRING, > "description" => "A public key in PEM Format. During validation, if a public key is provided, signature will be verified based on the key you provided here.", > "expressions-allowed" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:11:19 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:11:19 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1964) When controlling EAP 6 via Arquillian it sometimes starts to hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-1964. ----------------------------- Resolution: Out of Date > When controlling EAP 6 via Arquillian it sometimes starts to hang > ----------------------------------------------------------------- > > Key: WFLY-1964 > URL: https://issues.jboss.org/browse/WFLY-1964 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Radim Hatlapatka > Assignee: Andrew Rubinger > > See [ARQ-1464|https://issues.jboss.org/browse/ARQ-1464] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:13:31 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:13:31 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-982) Arquillian: IllegalStateException: standard-sockets -> http -> bound-port is undefined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-982. ---------------------------- Resolution: Out of Date > Arquillian: IllegalStateException: standard-sockets -> http -> bound-port is undefined > -------------------------------------------------------------------------------------- > > Key: WFLY-982 > URL: https://issues.jboss.org/browse/WFLY-982 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondrej Zizka > Assignee: Andrew Rubinger > Priority: Optional > > This happens sometimes in QA lab, probably due to slowness. > See https://hudson.qa.jboss.com/hudson/job/AS7-TS-valid-mvn-all-ipv6/56/testReport/org.jboss.as.arquillian.container.managed/InjectJndiContextTestCase/org_jboss_as_arquillian_container_managed_InjectJndiContextTestCase/ > {code} > java.lang.RuntimeException: java.lang.IllegalStateException: standard-sockets -> http -> bound-port is undefined > at org.jboss.as.arquillian.container.ManagementClient.getBinding(ManagementClient.java:222) > at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:111) > at org.jboss.as.arquillian.container.ManagementClient.getDeploymentMetaData(ManagementClient.java:117) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:150) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:156) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:123) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:266) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:122) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:90) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:258) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:234) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > Caused by: java.lang.IllegalStateException: standard-sockets -> http -> bound-port is undefined > at org.jboss.as.arquillian.container.ManagementClient.defined(ManagementClient.java:193) > at org.jboss.as.arquillian.container.ManagementClient.getBinding(ManagementClient.java:218) > ... 96 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:18:41 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:18:41 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-634) TS: Pass the path to docs/examples to the tests. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-634. ---------------------------- Resolution: Rejected > TS: Pass the path to docs/examples to the tests. > ------------------------------------------------ > > Key: WFLY-634 > URL: https://issues.jboss.org/browse/WFLY-634 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > In AS7, the path to the config file, passed in a system property, is only allowed to be a relative path. > In the testsuite, we would make use of absolute paths. > The reason is that we reuse the configs from docs/examples, and they change quite often, so having them in resources would be hardly maintainable. > However, docs/examples is not guaranteed to be always in the same place: E.g. for EAP, or for RPM-based installation of EAP it might end up in /var/docs or such. > I would like to pass some property from maven to the tests, but that results in absolute path. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:18:28 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:18:28 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-625) TS: Multiple Surefire executions - FAILURE in one supresses successive. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-625. ---------------------------- Resolution: Rejected > TS: Multiple Surefire executions - FAILURE in one supresses successive. > ----------------------------------------------------------------------- > > Key: WFLY-625 > URL: https://issues.jboss.org/browse/WFLY-625 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > > Jason wrote that we can live with this for CR1; However having it fixed for EAP is important. > Work in progress at http://jira.codehaus.org/browse/SUREFIRE-803 . > John Casey keeps an eye on this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:18:41 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:18:41 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-611) TS: Test output is not stored in ...-output.txt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-611. ---------------------------- Resolution: Rejected > TS: Test output is not stored in ...-output.txt > ----------------------------------------------- > > Key: WFLY-611 > URL: https://issues.jboss.org/browse/WFLY-611 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondra Chaloupka > > ./integration-tests.sh clean install -Dtest=org.jboss.as.test.integration.ejb.async.* -Dintegration.module -Dbasic.integration.tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:18:52 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:18:52 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-642) TS: -Dtest=** only matches one test per module. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-642. ---------------------------- Resolution: Out of Date > TS: -Dtest=** only matches one test per module. > ----------------------------------------------------------- > > Key: WFLY-642 > URL: https://issues.jboss.org/browse/WFLY-642 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Pavel Janousek > Assignee: Aslak Knutsen > > It seems like some regression. > When I've tried run like: > {code} > mvn3 clean install -Dts.basic '-Dtest=*.jaxrs.*' > {code} > I got this result: > {code} > [pjanouse at pjanouse testsuite]$ mvn3 clean install -Dts.basic '-Dtest=*.jaxrs.*' > Running org.jboss.as.test.smoke.jaxrs.JaxrsTestCase > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.689 sec > ... > ------ basic module: > Running org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.099 sec > ... > {code} > So you can see - Integration basic is invoked, but only TestCases org.jboss.as.test.smoke.jaxrs.JaxrsTestCase and org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCas were run although there are plenty of other TestCases fulfilled mask *\*.jaxrs.\** - many of them are localted in testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jaxrs/ + sub=dirs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:19:03 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:19:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-611) TS: Test output is not stored in ...-output.txt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reopened WFLY-611: ------------------------------ > TS: Test output is not stored in ...-output.txt > ----------------------------------------------- > > Key: WFLY-611 > URL: https://issues.jboss.org/browse/WFLY-611 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondra Chaloupka > > ./integration-tests.sh clean install -Dtest=org.jboss.as.test.integration.ejb.async.* -Dintegration.module -Dbasic.integration.tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:20:18 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:20:18 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-634) TS: Pass the path to docs/examples to the tests. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reopened WFLY-634: ------------------------------ > TS: Pass the path to docs/examples to the tests. > ------------------------------------------------ > > Key: WFLY-634 > URL: https://issues.jboss.org/browse/WFLY-634 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > In AS7, the path to the config file, passed in a system property, is only allowed to be a relative path. > In the testsuite, we would make use of absolute paths. > The reason is that we reuse the configs from docs/examples, and they change quite often, so having them in resources would be hardly maintainable. > However, docs/examples is not guaranteed to be always in the same place: E.g. for EAP, or for RPM-based installation of EAP it might end up in /var/docs or such. > I would like to pass some property from maven to the tests, but that results in absolute path. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:20:19 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:20:19 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-611) TS: Test output is not stored in ...-output.txt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-611. ---------------------------- Resolution: Out of Date > TS: Test output is not stored in ...-output.txt > ----------------------------------------------- > > Key: WFLY-611 > URL: https://issues.jboss.org/browse/WFLY-611 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondra Chaloupka > > ./integration-tests.sh clean install -Dtest=org.jboss.as.test.integration.ejb.async.* -Dintegration.module -Dbasic.integration.tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:20:29 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:20:29 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-625) TS: Multiple Surefire executions - FAILURE in one supresses successive. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reopened WFLY-625: ------------------------------ > TS: Multiple Surefire executions - FAILURE in one supresses successive. > ----------------------------------------------------------------------- > > Key: WFLY-625 > URL: https://issues.jboss.org/browse/WFLY-625 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > > Jason wrote that we can live with this for CR1; However having it fixed for EAP is important. > Work in progress at http://jira.codehaus.org/browse/SUREFIRE-803 . > John Casey keeps an eye on this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:20:29 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:20:29 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-634) TS: Pass the path to docs/examples to the tests. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-634. ---------------------------- Resolution: Out of Date > TS: Pass the path to docs/examples to the tests. > ------------------------------------------------ > > Key: WFLY-634 > URL: https://issues.jboss.org/browse/WFLY-634 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > In AS7, the path to the config file, passed in a system property, is only allowed to be a relative path. > In the testsuite, we would make use of absolute paths. > The reason is that we reuse the configs from docs/examples, and they change quite often, so having them in resources would be hardly maintainable. > However, docs/examples is not guaranteed to be always in the same place: E.g. for EAP, or for RPM-based installation of EAP it might end up in /var/docs or such. > I would like to pass some property from maven to the tests, but that results in absolute path. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:20:40 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:20:40 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-646) TS: Dynamic way to get ports of various services. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-646. ---------------------------- Resolution: Out of Date > TS: Dynamic way to get ports of various services. > ------------------------------------------------- > > Key: WFLY-646 > URL: https://issues.jboss.org/browse/WFLY-646 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > Original Estimate: 1 day > Remaining Estimate: 1 day > > {code:java} > private int getRecoveryManagerPort() throws IOException { > /* /socket-binding-group=standard-sockets/socket-binding=txn-recovery-environment:read-attribute(name=port) */ > final ModelNode address = new ModelNode(); > address.add("socket-binding-group", "standard-sockets"); > address.add("socket-binding", "txn-recovery-environment"); > final ModelNode operation = new ModelNode(); > operation.get(OP).set(READ_ATTRIBUTE_OPERATION); > operation.get(OP_ADDR).set(address); > operation.get("name").set("port"); > try { > return executeOperation(operation).asInt(); > } catch (MgmtOperationException ignored) { } > return -1; > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:21:02 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:21:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-625) TS: Multiple Surefire executions - FAILURE in one supresses successive. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-625. ---------------------------- Resolution: Out of Date > TS: Multiple Surefire executions - FAILURE in one supresses successive. > ----------------------------------------------------------------------- > > Key: WFLY-625 > URL: https://issues.jboss.org/browse/WFLY-625 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > > Jason wrote that we can live with this for CR1; However having it fixed for EAP is important. > Work in progress at http://jira.codehaus.org/browse/SUREFIRE-803 . > John Casey keeps an eye on this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:22:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-648) TS: Make Surefire test ordering configurable. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-648. ---------------------------- Resolution: Out of Date > TS: Make Surefire test ordering configurable. > --------------------------------------------- > > Key: WFLY-648 > URL: https://issues.jboss.org/browse/WFLY-648 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > Original Estimate: 4 hours > Remaining Estimate: 4 hours > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:27:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:27:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-601) TS: Logging issues (tracking) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-601. ---------------------------- Resolution: Out of Date > TS: Logging issues (tracking) > ----------------------------- > > Key: WFLY-601 > URL: https://issues.jboss.org/browse/WFLY-601 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Ondrej Zizka > > Some tests print to System.out, and also ex.printStackTrace(). Turn it to proper logging. Also check logging config. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:39:09 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 27 Mar 2017 08:39:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7593) JspTagTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-7593. ----------------------------- Resolution: Out of Date Closing based on last comment. It looks like inital problem is was not related to JSP handling but cdi invocation. > JspTagTestCase fails with security manager > ------------------------------------------ > > Key: WFLY-7593 > URL: https://issues.jboss.org/browse/WFLY-7593 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.jsp.JspTagTestCase#test* > {{./integration-tests.sh -DtestLogToFile=false -Dtest=JspTagTestCase -Dsecurity.manager}} > {code} > ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /ed26af0c-bc91-49ea-b6c3-196d33e8de5a/index2.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ )" of "org.apache.jasper.servlet.JasperLoader at a7277ba2") > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$425.00000000C40C2470.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$426.00000000C40CDD60.call(Unknown Source) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(AccessController.java:650) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/ed26af0c-bc91-49ea-b6c3-196d33e8de5a.war/ )" of "org.apache.jasper.servlet.JasperLoader at a7277ba2") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.Class.getClassLoader(Class.java:442) > at org.jboss.as.weld.injection.InjectionTargets.createInjectionTarget(InjectionTargets.java:63) > at org.jboss.as.weld.deployment.WeldClassIntrospector.getInjectionTarget(WeldClassIntrospector.java:90) > at org.jboss.as.weld.deployment.WeldClassIntrospector.createInstance(WeldClassIntrospector.java:102) > at org.jboss.as.ee.component.ComponentRegistry.createInstance(ComponentRegistry.java:85) > at org.jboss.as.web.common.WebInjectionContainer.newInstance(WebInjectionContainer.java:77) > at org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager.newInstance(UndertowJSPInstanceManager.java:75) > at org.apache.jsp.index2_jsp._jspx_meth_my_005ftag_005f0(index2_jsp.java:128) > at org.apache.jsp.index2_jsp._jspService(index2_jsp.java:99) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) > ... 48 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 09:40:07 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 27 Mar 2017 09:40:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384559#comment-13384559 ] RH Bugzilla Integration commented on JBJCA-1341: ------------------------------------------------ Radovan Netuka changed the Status of [bug 1276052|https://bugzilla.redhat.com/show_bug.cgi?id=1276052] from ASSIGNED to MODIFIED > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 10:05:38 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Mon, 27 Mar 2017 10:05:38 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-79) Test Classic search/Advanced search on middleware pages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384580#comment-13384580 ] Sunil kondkar commented on HAWKULARQE-79: ----------------------------------------- Completed Updating Manual tests in Polarion. Completed test case execution against CFME version: 5.8.0.7.20170321164727_1c97ccd Test Run: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%2058-DR3 There is one failed test case due to below issue: https://bugzilla.redhat.com/show_bug.cgi?id=1436243 > Test Classic search/Advanced search on middleware pages > ------------------------------------------------------- > > Key: HAWKULARQE-79 > URL: https://issues.jboss.org/browse/HAWKULARQE-79 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to test classic/advanced search options on middleware pages except on topology page. > Reference Bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1403213 > Tasks: > * Review existing search test cases > * Add any missing test cases > * Execute test cases on CFME 5.8.0.7 > * Report any bugs > * Add automation tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 10:05:37 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Mon, 27 Mar 2017 10:05:37 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated JBJCA-1341: ------------------------------ Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/613, https://github.com/ironjacamar/ironjacamar/pull/612, https://github.com/ironjacamar/ironjacamar/pull/611, https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607, https://github.com/ironjacamar/ironjacamar/pull/608 (was: https://github.com/ironjacamar/ironjacamar/pull/613, https://github.com/ironjacamar/ironjacamar/pull/612, https://github.com/ironjacamar/ironjacamar/pull/611) > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 10:05:47 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Mon, 27 Mar 2017 10:05:47 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-79) Test Classic search/Advanced search on middleware pages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar updated HAWKULARQE-79: ------------------------------------ Description: Task to test classic/advanced search options on middleware pages except on topology page. Reference Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1403213 Tasks: * Review existing search test cases * Add any missing test cases * Execute test cases on CFME 5.8.0.7 * Report any bugs- * Add automation tests was: Task to test classic/advanced search options on middleware pages except on topology page. Reference Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1403213 Tasks: * Review existing search test cases * Add any missing test cases * Execute test cases on CFME 5.8.0.7 * Report any bugs * Add automation tests > Test Classic search/Advanced search on middleware pages > ------------------------------------------------------- > > Key: HAWKULARQE-79 > URL: https://issues.jboss.org/browse/HAWKULARQE-79 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to test classic/advanced search options on middleware pages except on topology page. > Reference Bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1403213 > Tasks: > * Review existing search test cases > * Add any missing test cases > * Execute test cases on CFME 5.8.0.7 > * Report any bugs- > * Add automation tests -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 10:32:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 27 Mar 2017 10:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8451) org.wildfly.clustering.web.session.IdentifierExternalizerTestCase#toHex fails on JDK9 b162 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384615#comment-13384615 ] Radoslav Husar commented on WFLY-8451: -------------------------------------- Needs some sort of `-addmods java.xml.bind` at the moment. > org.wildfly.clustering.web.session.IdentifierExternalizerTestCase#toHex fails on JDK9 b162 > ------------------------------------------------------------------------------------------ > > Key: WFLY-8451 > URL: https://issues.jboss.org/browse/WFLY-8451 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > testHex(org.wildfly.clustering.web.session.IdentifierExternalizerTestCase) Time elapsed: 0.008 sec <<< ERROR! > java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476) > at org.wildfly.clustering.web.IdentifierExternalizer$3.writeObject(IdentifierExternalizer.java:74) > at org.wildfly.clustering.web.IdentifierExternalizer$3.writeObject(IdentifierExternalizer.java:71) > at org.wildfly.clustering.web.session.IdentifierExternalizerTestCase.test(IdentifierExternalizerTestCase.java:97) > at org.wildfly.clustering.web.session.IdentifierExternalizerTestCase.testHex(IdentifierExternalizerTestCase.java:61) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 10:34:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 27 Mar 2017 10:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2577) ModelOnlyResourceDefinition does not expose a constructor that takes a Parameters object. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar reassigned WFCORE-2577: -------------------------------------- Assignee: Radoslav Husar > ModelOnlyResourceDefinition does not expose a constructor that takes a Parameters object. > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2577 > URL: https://issues.jboss.org/browse/WFCORE-2577 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Radoslav Husar > Priority: Minor > > It's better to wire up resource definitions using Parameters so we should support it for this one too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 10:34:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Mon, 27 Mar 2017 10:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8449) EJB contextData not sent back to client in response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan reopened WFLY-8449: ------------------------------ > EJB contextData not sent back to client in response > --------------------------------------------------- > > Key: WFLY-8449 > URL: https://issues.jboss.org/browse/WFLY-8449 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > Labels: ejb > Fix For: 11.0.0.Alpha1 > > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 11:04:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Mon, 27 Mar 2017 11:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2581) There isn't possible change value for given alias in Credential Store over CLI. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet moved ELY-676 to WFCORE-2581: ----------------------------------------------- Project: WildFly Core (was: WildFly Elytron) Key: WFCORE-2581 (was: ELY-676) Component/s: Security (was: Credential Store) Affects Version/s: 3.0.0.Beta11 (was: 1.1.0.Beta10) > There isn't possible change value for given alias in Credential Store over CLI. > ------------------------------------------------------------------------------- > > Key: WFCORE-2581 > URL: https://issues.jboss.org/browse/WFCORE-2581 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta11 > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Priority: Critical > > There isn't possible change value for given alias in Credential Store over CLI. > I expected something like this > {code} > /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue) > {code} > Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store. > {code} > /subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue") > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 11:08:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Mon, 27 Mar 2017 11:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2581) There isn't possible change value for given alias in Credential Store over CLI. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2581: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Peter Skopek) > There isn't possible change value for given alias in Credential Store over CLI. > ------------------------------------------------------------------------------- > > Key: WFCORE-2581 > URL: https://issues.jboss.org/browse/WFCORE-2581 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta11 > Reporter: Hynek ?v?bek > Assignee: ehsavoie Hugonnet > Priority: Critical > > There isn't possible change value for given alias in Credential Store over CLI. > I expected something like this > {code} > /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue) > {code} > Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store. > {code} > /subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue") > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 11:16:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Mon, 27 Mar 2017 11:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2582) jboss-cli.bat script is unable to start on Windows, if JBOSS_HOME folder contains '!' character In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise moved JBEAP-9918 to WFCORE-2582: ----------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2582 (was: JBEAP-9918) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: (was: 7.1.0.DR15) Affects Testing: (was: Regression) > jboss-cli.bat script is unable to start on Windows, if JBOSS_HOME folder contains '!' character > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2582 > URL: https://issues.jboss.org/browse/WFCORE-2582 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > jboss-cli.bat script is unable to start on Windows, if JBOSS_HOME folder contains '!' character, if '!' character is not at the end of the name of JBOSS_HOME folder. > jboss-cli.bat script is unable to start on Windows if JBOSS_HOME ends with exclamation mark, but it is covered by JBEAP-249 > {noformat} > C:\Users\Administrator\playground\7.1.0.DR15\jboss!eap\bin>jboss-cli.bat > The system cannot find the path specified. > The system cannot find the path specified. > Could not locate "C:\Users\Administrator\playground\7.1.0.DR15\jbosseap\bin\jboss-modules.jar". > Please check that you are in the bin directory when running this script. > Press any key to continue . . . > C:\Users\Administrator\playground\7.1.0.DR15\jboss!eap\bin>jboss-cli.bat > {noformat} > * This issue is caused by JBEAP-9699 > *Workaround:* > Rename JBOSS_HOME folder -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 12:44:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Mon, 27 Mar 2017 12:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8455) Upgrade HAL to 2.9.6.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-8455: --------------------------------- Summary: Upgrade HAL to 2.9.6.Final Key: WFLY-8455 URL: https://issues.jboss.org/browse/WFLY-8455 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 13:01:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 27 Mar 2017 13:01:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1034) Allow HTTP authentication mechanisms to use Status 500 / Internal Server Error In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1034: ------------------------------------- Summary: Allow HTTP authentication mechanisms to use Status 500 / Internal Server Error Key: ELY-1034 URL: https://issues.jboss.org/browse/ELY-1034 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta34 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 13:04:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 27 Mar 2017 13:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1034) Allow HTTP authentication mechanisms to use Status 500 / Internal Server Error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1034: ---------------------------------- Description: Some mechanisms are unable to operate correctly due to internal errors / configuration issues. When this happens they should be able to provide a responder which sets the status code to 500. However if other mechanisms can respond they should and the 500 be dropped. > Allow HTTP authentication mechanisms to use Status 500 / Internal Server Error > ------------------------------------------------------------------------------ > > Key: ELY-1034 > URL: https://issues.jboss.org/browse/ELY-1034 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Some mechanisms are unable to operate correctly due to internal errors / configuration issues. > When this happens they should be able to provide a responder which sets the status code to 500. However if other mechanisms can respond they should and the 500 be dropped. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 14:31:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 14:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2562) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2562: ------------------------------------- Issue Type: Bug (was: Support Patch) > NullPointerException when removing configuration history > -------------------------------------------------------- > > Key: WFCORE-2562 > URL: https://issues.jboss.org/browse/WFCORE-2562 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Brian Stansberry > > org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. > If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. > This method is used while removing old configuration history directories during boot, and the NullPointerException causes the EAP boot to abort. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 14:31:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 14:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2562) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2562: ---------------------------------------- Assignee: Ken Wills (was: Brian Stansberry) > NullPointerException when removing configuration history > -------------------------------------------------------- > > Key: WFCORE-2562 > URL: https://issues.jboss.org/browse/WFCORE-2562 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Ken Wills > > org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. > If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. > This method is used while removing old configuration history directories during boot, and the NullPointerException causes the EAP boot to abort. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 14:38:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 14:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2558) If an op fails but isn't rolled back, the response doesn't report non-rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384768#comment-13384768 ] Brian Stansberry commented on WFCORE-2558: ------------------------------------------ A fix for this is currently one of the commits on https://github.com/bstansberry/wildfly-core/commits/WFCORE-1762 but that branch is not ready for a PR. But if someone wants this fixed before then, that commit is a good place to start. (Basic manual testing shows it works.) > If an op fails but isn't rolled back, the response doesn't report non-rollback > ------------------------------------------------------------------------------ > > Key: WFCORE-2558 > URL: https://issues.jboss.org/browse/WFCORE-2558 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If an op rolls back, the response includes "rolled-back"=>true. But if a failure occurs but the op doesn't roll back (because the rollback-on-runtime-failure operation header was set to false) there is no "rolled-back"=>false in the response. The effect of the operation is therefore unclear to the user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 15:07:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 27 Mar 2017 15:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-152) Rewriting the property attribute on custom handlers or formatters does not unset values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFCORE-152: --------------------------------- Description: I'm not setting a target for this as likely part of this needs to be solved in the logmanager. Currently rewriting properties does not unset properties that have been removed from the property map. It seems simple enough to just pass a {{null}} value to the property and then remove the property, but this won't work for primitives. >From the WildFly perspective there is no way from the configuration API to determine the type for a property to set. This is the part that should probably be handled in the logmanager. WildFly will need to set the value to {{null}} once this is solved on the logmanager side. was: I'm not setting a target for this as likely part of this needs to be solved in the logmanager. Currently rewriting properties does not unset properties that have been removed from the property map. It seems simple enough to just pass a {{null}} value to the property and then remove the property, but this won't work for primitives. >From the WildFly perspective there is know way from the configuration API to determine the type for a property to set. This is the part that should probably be handled in the logmanager. WildFly will need to set the value to {{null}} once this is solved on the logmanager side. > Rewriting the property attribute on custom handlers or formatters does not unset values > --------------------------------------------------------------------------------------- > > Key: WFCORE-152 > URL: https://issues.jboss.org/browse/WFCORE-152 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > I'm not setting a target for this as likely part of this needs to be solved in the logmanager. Currently rewriting properties does not unset properties that have been removed from the property map. It seems simple enough to just pass a {{null}} value to the property and then remove the property, but this won't work for primitives. > From the WildFly perspective there is no way from the configuration API to determine the type for a property to set. This is the part that should probably be handled in the logmanager. WildFly will need to set the value to {{null}} once this is solved on the logmanager side. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 15:28:00 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Mon, 27 Mar 2017 15:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8176) CS tool, --salt and --iteration parameters unintentionally required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Skopek reassigned WFLY-8176: ---------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > CS tool, --salt and --iteration parameters unintentionally required > ------------------------------------------------------------------- > > Key: WFLY-8176 > URL: https://issues.jboss.org/browse/WFLY-8176 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Peter Skopek > Priority: Blocker > Labels: credential-store > > Any command have to contain --salt and --iteration parameters to be sucessfull, otherwise NPE occures. However this parameters are necesarry only in margin case > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} > with these parameters command success > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230 > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230"}) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 16:15:01 2017 From: issues at jboss.org (Sachin Gupta (JIRA)) Date: Mon, 27 Mar 2017 16:15:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1498) Drools Workbench WAR deployment fails if JBOSS EAP 7.x running in Domain Mode In-Reply-To: References: Message-ID: Sachin Gupta created DROOLS-1498: ------------------------------------ Summary: Drools Workbench WAR deployment fails if JBOSS EAP 7.x running in Domain Mode Key: DROOLS-1498 URL: https://issues.jboss.org/browse/DROOLS-1498 Project: Drools Issue Type: Bug Components: build, core engine, tools Affects Versions: 6.5.0.Final Environment: Red Hat Linux, JBOSS EAP 7.0.4 runnig in Domain configuration Reporter: Sachin Gupta Assignee: Petr ?irok? Priority: Critical Fix For: 6.5.0.Final When running JBOSS EAP 7.0.x in Domain configuration mode, deployment of Drools Workbench (6.5 Final - kie-drools-wb-6.5.0.Final-eap7.war) fails. Same WAR file when deployed to a standalone configuration server, works well. Errors: _org.jboss.msc.service.StartException in service jboss.deployment.unit."kie-drools-wb-6.5.0.Final-eap7.war".WeldStartService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 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: org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions: Exception 0 : org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl.init() on org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl at 4be9bb38 at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:171) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl$Proxy$_$$_WeldClientProxy.toString(Unknown Source) at org.kie.internal.runtime.cdi.BootOnLoadExtension.runPostConstruct(BootOnLoadExtension.java:69) at org.kie.internal.runtime.cdi.BootOnLoadExtension.afterDeploymentValidation(BootOnLoadExtension.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:309) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:287) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:271) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:260) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35) at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:449) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 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.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 37 more Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.kie.workbench.drools.backend.server.LuceneConfigProducer.setup() on org.kie.workbench.drools.backend.server.LuceneConfigProducer at 34fc780b at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:162) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:123) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:158) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:363) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:374) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:123) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:158) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:150) at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:75) at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:116) at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.dashbuilder.dataset.DataSetDefRegistryCDI$Proxy$_$$_WeldClientProxy.getDataSetDef(Unknown Source) at org.jbpm.kie.services.impl.query.QueryServiceImpl.registerQuery(QueryServiceImpl.java:122) at org.jbpm.kie.services.impl.query.QueryServiceImpl.init(QueryServiceImpl.java:109) at org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl.init(QueryServiceCDIImpl.java:69) ... 42 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 96 more Caused by: java.lang.RuntimeException: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/opt/app/jboss/jboss-eap-7.0/.index/datasets/write.lock at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryLuceneIndex.(DirectoryLuceneIndex.java:53) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryType$2.newIndex(DirectoryType.java:63) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryFactory.(DirectoryFactory.java:54) at org.uberfire.ext.metadata.backend.lucene.LuceneConfigBuilder.build(LuceneConfigBuilder.java:110) at org.kie.workbench.drools.backend.server.LuceneConfigProducer.setup(LuceneConfigProducer.java:58) ... 101 more Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/opt/app/jboss/jboss-eap-7.0/.index/datasets/write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.(IndexWriter.java:602) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryLuceneIndex.(DirectoryLuceneIndex.java:50) ... 105 more at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:37) at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:449) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more 2017-03-27 14:20:03,538 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 196) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "kie-drools-wb-6.5.0.Final-eap7.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"kie-drools-wb-6.5.0.Final-eap7.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"kie-drools-wb-6.5.0.Final-eap7.war\".WeldStartService: Failed to start service Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions: Exception 0 : org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl.init() on org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl at 4be9bb38 at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:171) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl$Proxy$_$$_WeldClientProxy.toString(Unknown Source) at org.kie.internal.runtime.cdi.BootOnLoadExtension.runPostConstruct(BootOnLoadExtension.java:69) at org.kie.internal.runtime.cdi.BootOnLoadExtension.afterDeploymentValidation(BootOnLoadExtension.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:309) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:287) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:271) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:260) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35) at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:449) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 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.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 37 more Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.kie.workbench.drools.backend.server.LuceneConfigProducer.setup() on org.kie.workbench.drools.backend.server.LuceneConfigProducer at 34fc780b at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:162) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:123) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:158) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:363) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:374) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:123) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:158) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:150) at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:75) at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:116) at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.dashbuilder.dataset.DataSetDefRegistryCDI$Proxy$_$$_WeldClientProxy.getDataSetDef(Unknown Source) at org.jbpm.kie.services.impl.query.QueryServiceImpl.registerQuery(QueryServiceImpl.java:122) at org.jbpm.kie.services.impl.query.QueryServiceImpl.init(QueryServiceImpl.java:109) at org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl.init(QueryServiceCDIImpl.java:69) ... 42 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 96 more Caused by: java.lang.RuntimeException: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/opt/app/jboss/jboss-eap-7.0/.index/datasets/write.lock at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryLuceneIndex.(DirectoryLuceneIndex.java:53) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryType$2.newIndex(DirectoryType.java:63) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryFactory.(DirectoryFactory.java:54) at org.uberfire.ext.metadata.backend.lucene.LuceneConfigBuilder.build(LuceneConfigBuilder.java:110) at org.kie.workbench.drools.backend.server.LuceneConfigProducer.setup(LuceneConfigProducer.java:58) ... 101 more Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/opt/app/jboss/jboss-eap-7.0/.index/datasets/write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.(IndexWriter.java:602) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryLuceneIndex.(DirectoryLuceneIndex.java:50) ... 105 more "}} 2017-03-27 14:20:03,539 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 196) WFLYSRV0021: Deploy of deployment "kie-drools-wb-6.5.0.Final-eap7.war" was rolled back with the following failure message: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"kie-drools-wb-6.5.0.Final-eap7.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"kie-drools-wb-6.5.0.Final-eap7.war\".WeldStartService: Failed to start service Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions: Exception 0 : org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl.init() on org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl at 4be9bb38 at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:171) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl$Proxy$_$$_WeldClientProxy.toString(Unknown Source) at org.kie.internal.runtime.cdi.BootOnLoadExtension.runPostConstruct(BootOnLoadExtension.java:69) at org.kie.internal.runtime.cdi.BootOnLoadExtension.afterDeploymentValidation(BootOnLoadExtension.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:309) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:287) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:271) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:260) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35) at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:449) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 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.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 37 more Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.kie.workbench.drools.backend.server.LuceneConfigProducer.setup() on org.kie.workbench.drools.backend.server.LuceneConfigProducer at 34fc780b at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:162) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:123) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:158) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:363) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:374) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:123) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:158) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:150) at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:75) at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:116) at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.dashbuilder.dataset.DataSetDefRegistryCDI$Proxy$_$$_WeldClientProxy.getDataSetDef(Unknown Source) at org.jbpm.kie.services.impl.query.QueryServiceImpl.registerQuery(QueryServiceImpl.java:122) at org.jbpm.kie.services.impl.query.QueryServiceImpl.init(QueryServiceImpl.java:109) at org.jbpm.services.cdi.impl.query.QueryServiceCDIImpl.init(QueryServiceCDIImpl.java:69) ... 42 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 96 more Caused by: java.lang.RuntimeException: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/opt/app/jboss/jboss-eap-7.0/.index/datasets/write.lock at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryLuceneIndex.(DirectoryLuceneIndex.java:53) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryType$2.newIndex(DirectoryType.java:63) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryFactory.(DirectoryFactory.java:54) at org.uberfire.ext.metadata.backend.lucene.LuceneConfigBuilder.build(LuceneConfigBuilder.java:110) at org.kie.workbench.drools.backend.server.LuceneConfigProducer.setup(LuceneConfigProducer.java:58) ... 101 more Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/opt/app/jboss/jboss-eap-7.0/.index/datasets/write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.(IndexWriter.java:602) at org.uberfire.ext.metadata.backend.lucene.index.directory.DirectoryLuceneIndex.(DirectoryLuceneIndex.java:50) ... 105 more "}} 2017-03-27 14:20:03,566 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 197) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'kie-drools-wb-6.5.0.Final-eap7.war#org.jbpm.domain' 2017-03-27 14:20:03,575 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 197) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'kie-drools-wb-6.5.0.Final-eap7.war#org.jbpm.domain' 2017-03-27 14:20:03,618 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 199) ISPN000310: Starting cluster-wide rebalance for cache dist, topology CacheTopology{id=9, rebalanceId=4, currentCH=DefaultConsistentHash{ns=80, owners = (2)[master:MSISRVCS_zld04668B: 40+14, master:MSIGUI_zld04668B: 40+13]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[master:MSISRVCS_zld04668B: 40+40, master:MSIGUI_zld04668B: 40+40]}, unionCH=null, actualMembers=[master:MSISRVCS_zld04668B, master:MSIGUI_zld04668B]} 2017-03-27 14:20:03,619 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 199) ISPN000029: Passivating all entries to disk 2017-03-27 14:20:03,621 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 199) ISPN000030: Passivated 0 entries in 2 milliseconds 2017-03-27 14:20:03,625 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 197) ISPN000310: Starting cluster-wide rebalance for cache client-mappings, topology CacheTopology{id=9, rebalanceId=4, currentCH=DefaultConsistentHash{ns=80, owners = (2)[master:MSISRVCS_zld04668B: 40+14, master:MSIGUI_zld04668B: 40+13]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[master:MSISRVCS_zld04668B: 40+40, master:MSIGUI_zld04668B: 40+40]}, unionCH=null, actualMembers=[master:MSISRVCS_zld04668B, master:MSIGUI_zld04668B]} 2017-03-27 14:20:03,629 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 199) WFLYCLINF0003: Stopped dist cache from ejb container 2017-03-27 14:20:03,629 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 197) WFLYCLINF0003: Stopped client-mappings cache from ejb container 2017-03-27 14:20:03,649 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t6) ISPN000336: Finished cluster-wide rebalance for cache dist, topology id = 9 2017-03-27 14:20:03,653 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t6) ISPN000336: Finished cluster-wide rebalance for cache client-mappings, topology id = 9 2017-03-27 14:20:03,863 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment kie-drools-wb-6.5.0.Final-eap7.war (runtime-name: kie-drools-wb-6.5.0.Final-eap7.war) in 323ms _ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 16:54:00 2017 From: issues at jboss.org (Stephen Felts (JIRA)) Date: Mon, 27 Mar 2017 16:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-265) JDK9 In-Reply-To: References: Message-ID: Stephen Felts created JASSIST-265: ------------------------------------- Summary: JDK9 Key: JASSIST-265 URL: https://issues.jboss.org/browse/JASSIST-265 Project: Javassist Issue Type: Bug Affects Versions: 3.22.0-CR1 Reporter: Stephen Felts Assignee: Shigeru Chiba When running with 3.22.0-CR1 nightly with 4 updates on JDK9 Jigsaw b162 with --permit-illegal-access set, the following warnings are generated. WARNING: Illegal access by javassist.ClassPool (file:gradle_cache/caches/modules-2/files-2.1/org.javassist/javassist/3.2 2.0-CR1-4-g6a3ed31/92a4768aa45d8e04158b4ad84daf7bc8c3296893/javassist-3.22.0-CR1-4-g6a3ed31.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Illegal access by javassist.util.proxy.SecurityActions (file:gradle_cache/caches/modules-2/files-2.1/org.javass ist/javassist/3.22.0-CR1-4-g6a3ed31/92a4768aa45d8e04158b4ad84daf7bc8c3296893/javassist-3.22.0-CR1-4-g6a3ed31.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 16:56:00 2017 From: issues at jboss.org (Stephen Felts (JIRA)) Date: Mon, 27 Mar 2017 16:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-265) JDK9 Reference to Internal API's In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Felts updated JASSIST-265: ---------------------------------- Summary: JDK9 Reference to Internal API's (was: JDK9) > JDK9 Reference to Internal API's > -------------------------------- > > Key: JASSIST-265 > URL: https://issues.jboss.org/browse/JASSIST-265 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.22.0-CR1 > Reporter: Stephen Felts > Assignee: Shigeru Chiba > > When running with 3.22.0-CR1 nightly with 4 updates on JDK9 Jigsaw b162 with > --permit-illegal-access set, the following warnings are generated. > WARNING: Illegal access by javassist.ClassPool (file:gradle_cache/caches/modules-2/files-2.1/org.javassist/javassist/3.2 > 2.0-CR1-4-g6a3ed31/92a4768aa45d8e04158b4ad84daf7bc8c3296893/javassist-3.22.0-CR1-4-g6a3ed31.jar) to method > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) > WARNING: Illegal access by javassist.util.proxy.SecurityActions (file:gradle_cache/caches/modules-2/files-2.1/org.javass > ist/javassist/3.22.0-CR1-4-g6a3ed31/92a4768aa45d8e04158b4ad84daf7bc8c3296893/javassist-3.22.0-CR1-4-g6a3ed31.jar) to method > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:09:00 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8178) Send module unavailable notification when server suspends In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8178: ------------------------------- Fix Version/s: 11.0.0.Alpha1 > Send module unavailable notification when server suspends > --------------------------------------------------------- > > Key: WFLY-8178 > URL: https://issues.jboss.org/browse/WFLY-8178 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Fix For: 11.0.0.Alpha1 > > > Add a mechanism to send module unavailable notification to client when server suspends in the new EJB code. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:24:00 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7303) Unignore tests in org.jboss.as.test.integration.ejb.mdb.MDBTestCase and org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene reopened WFLY-7303: -------------------------------- > Unignore tests in org.jboss.as.test.integration.ejb.mdb.MDBTestCase and org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7303 > URL: https://issues.jboss.org/browse/WFLY-7303 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Farah Juma > Assignee: Farah Juma > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > > When tests in {{org.jboss.as.test.integration.ejb.mdb.MDBTestCase}} and {{org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase}} fail, the tests that get run after these ones fail as well. These tests in MDBTestCases will be fixed during Phase III Remoting 5 integration but temporarily ignoring them for now to try to get the CI job in better shape. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:05 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8453) Rename WildFly Elytron Subsystem to wildfly-elytron-integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8453: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Rename WildFly Elytron Subsystem to wildfly-elytron-integration > --------------------------------------------------------------- > > Key: WFLY-8453 > URL: https://issues.jboss.org/browse/WFLY-8453 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:05 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8449) EJB contextData not sent back to client in response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8449: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > EJB contextData not sent back to client in response > --------------------------------------------------- > > Key: WFLY-8449 > URL: https://issues.jboss.org/browse/WFLY-8449 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > Labels: ejb > Fix For: 11.0.0.Beta1 > > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:05 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8390) Correct RemotingLoginModule test failures. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8390: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Correct RemotingLoginModule test failures. > ------------------------------------------ > > Key: WFLY-8390 > URL: https://issues.jboss.org/browse/WFLY-8390 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:05 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8455) Upgrade HAL to 2.9.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8455: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Upgrade HAL to 2.9.6.Final > -------------------------- > > Key: WFLY-8455 > URL: https://issues.jboss.org/browse/WFLY-8455 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8250) Ensure all Elytron subsystem resources that depend on the core services also record a capability dependency. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8250: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Ensure all Elytron subsystem resources that depend on the core services also record a capability dependency. > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-8250 > URL: https://issues.jboss.org/browse/WFLY-8250 > Project: WildFly > Issue Type: Enhancement > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Beta1 > > > This builds on https://issues.jboss.org/browse/WFCORE-1106 so we can skip runtime steps when the dependent services are not available. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8049) Update Artemis SQL statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-8049: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Update Artemis SQL statements > ------------------------------ > > Key: WFLY-8049 > URL: https://issues.jboss.org/browse/WFLY-8049 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 11.0.0.Beta1 > > > After ARTEMIS-938, SQL statements for Artemis JDBC store uses BIGINT for ids instead of INT. > The SQL statement used by WildFly (in modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/database/journal-sql.properties) must be updated to also use BIGINT -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7986) Add some exclusions to the 'org.wildfly.extension.elytron' module. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7986: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add some exclusions to the 'org.wildfly.extension.elytron' module. > ------------------------------------------------------------------ > > Key: WFLY-7986 > URL: https://issues.jboss.org/browse/WFLY-7986 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Beta1 > > > Likely to be something like: - > bq. > bq. > bq. > bq. > bq. > Although capabilities also needs to be double checked, this may be moved and hidden using standard Java visibility modifiers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7822) The default-security-domain attribute in the Undertow subsystem should not support expressions. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7822: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > The default-security-domain attribute in the Undertow subsystem should not support expressions. > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7822 > URL: https://issues.jboss.org/browse/WFLY-7822 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Stuart Douglas > Fix For: 11.0.0.Beta1 > > > This attribute may be deprecated and removed at some point when we start to transition off PicketBox but for now it leads to a service dependency being set based on the value so should not support expressions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7816) Camel CXF version not compatible with WildFly CXF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7816: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Camel CXF version not compatible with WildFly CXF > ------------------------------------------------- > > Key: WFLY-7816 > URL: https://issues.jboss.org/browse/WFLY-7816 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 10.1.0.Final > Reporter: Thomas Diesler > Assignee: Alessio Soldano > Fix For: 10.2.0.Final, 11.0.0.Beta1 > > > cxf-3.1.9 distributed with camel-2.19.x is not compatible with cxf-3.1.6 from wildfly-10.1.0.Final > {code} > Caused by: java.lang.NoSuchMethodError: org.apache.cxf.message.Message.remove(Ljava/lang/Class;)Ljava/lang/Object; > at org.apache.camel.component.cxf.CxfEndpoint$CamelCxfClientImpl.setParameters(CxfEndpoint.java:1239) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:470) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:416) > at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:133) > {code} > CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1546 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7795) org.jboss.sasl classes still making it into jboss-client.jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7795: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > org.jboss.sasl classes still making it into jboss-client.jar > ------------------------------------------------------------ > > Key: WFLY-7795 > URL: https://issues.jboss.org/browse/WFLY-7795 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > The dependencies should have been removed but maybe this is still coming in as a transitive dependency from elsewhere. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7664) Missing default values in ldap-key-store description in management model. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7664: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Missing default values in ldap-key-store description in management model. > ------------------------------------------------------------------------- > > Key: WFLY-7664 > URL: https://issues.jboss.org/browse/WFLY-7664 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 11.0.0.Beta1 > > > Some attributes of Elytron {{ldap-key-store}} resource have defined some default value, but description of these attributes in CLI is missing default values. According to XSD following attributes of {{ldap-key-store}} have assigned some default value: > * {{search-recursive}} has default value {{true}} > * {{search-time-limit}} has default value {{10000}} > * {{filter-alias}} has default value {{(alias-attribute=\{0\})}} > * {{filter-certificate}} has default value {{(certificate-attribute=\{0\})}} > * {{filter-iterate}} has default value {{(alias-attribute=*)}} > * {{alias-attribute}} has default value {{cn}} > * {{certificate-attribute}} has default value {{usercertificate}} > * {{certificate-type}} has default value {{X.509}} > * {{certificate-chain-attribute}} has default value {{userSMIMECertificate}} > * {{certificate-chain-encoding}} has default value {{PKCS7}} > * {{key-attribute}} has default value {{userPKCS12}} > * {{key-type}} has default value {{PKCS12}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:06 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7639) Missing XSD for wildfly-config.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7639: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Missing XSD for wildfly-config.xml > ---------------------------------- > > Key: WFLY-7639 > URL: https://issues.jboss.org/browse/WFLY-7639 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Beta1 > > > There is a new client configuration required in `wildfly-config.xml` (more in JBEAP-7104), but the `docs/schema` folder doesn't contain its XSD (schema definition). > We have to provide one with a sufficient description of the elements and attributes. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7564) EJB Attachment protocol mismatch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7564: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > EJB Attachment protocol mismatch > -------------------------------- > > Key: WFLY-7564 > URL: https://issues.jboss.org/browse/WFLY-7564 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good. > The fix: > * In protocol 3 and higher, always read and write a packed integer > * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present > Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source attribute should not be an attribute of all JGroups protocols In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7361: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > data-source attribute should not be an attribute of all JGroups protocols > ------------------------------------------------------------------------- > > Key: WFLY-7361 > URL: https://issues.jboss.org/browse/WFLY-7361 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference. > This can be registered separately from the generic protocol resource definition. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7419) Add resteasy wadl as a module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7419: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add resteasy wadl as a module > ----------------------------- > > Key: WFLY-7419 > URL: https://issues.jboss.org/browse/WFLY-7419 > Project: WildFly > Issue Type: Enhancement > Components: REST > Affects Versions: 10.1.0.Final, 11.0.0.Alpha1 > Reporter: Frank Langelage > Assignee: Alessio Soldano > Fix For: 10.2.0.Final, 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7304: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Compensations subsystem > ----------------------- > > Key: WFLY-7304 > URL: https://issues.jboss.org/browse/WFLY-7304 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 11.0.0.Beta1 > > > Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too. > The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7303) Unignore tests in org.jboss.as.test.integration.ejb.mdb.MDBTestCase and org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7303: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Unignore tests in org.jboss.as.test.integration.ejb.mdb.MDBTestCase and org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7303 > URL: https://issues.jboss.org/browse/WFLY-7303 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Farah Juma > Assignee: Farah Juma > Labels: affects_elytron > Fix For: 11.0.0.Beta1 > > > When tests in {{org.jboss.as.test.integration.ejb.mdb.MDBTestCase}} and {{org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase}} fail, the tests that get run after these ones fail as well. These tests in MDBTestCases will be fixed during Phase III Remoting 5 integration but temporarily ignoring them for now to try to get the CI job in better shape. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7537) Review NamingContext.check() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7537: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Review NamingContext.check() method > ----------------------------------- > > Key: WFLY-7537 > URL: https://issues.jboss.org/browse/WFLY-7537 > Project: WildFly > Issue Type: Task > Components: Naming > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 11.0.0.Beta1 > > > The new naming client is sending in a SimpleName where the lookup was performed using a String. > When a SecurityManager is installed the check() method of NamingContext is called and results in the following error: - > {noformat} > javax.naming.InvalidNameException: Not a composite name: jms > at javax.naming.CompositeName.addAll(CompositeName.java:472) > at org.jboss.as.naming.NamingContext.check(NamingContext.java:592) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:127) > at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73) > 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) > {noformat} > A fix has been applied to convert the incoming name to a CompositeName but as we deliberately have a SimpleName to avoid CompositeName I wonder if that is completely correct. > Some other options I think of: - > 1. Stick with current fix. > 2 The client should convert to CompositeName before sending. > 3. Manually iterate the segments if not a CompositeName > 4. Check if the NamingStore really needs to use a CompositeName -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7161) EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7161: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7161 > URL: https://issues.jboss.org/browse/WFLY-7161 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Radim Hatlapatka > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > When having deployment with EJB which is invoked from servlet and the EJB has defined specific security domain to use via {{@SecurityDomain}} annotation, the ejb method invocation fails when there is defined elytron security domain for undertow and old security domain for EJBs with \[1\]. > Note when having both security domains setup only using old security subsystems, the access is allowed as expected. > Marking as critical as this should work. If it is not considered supported use case then there should be at least shown proper warning in logs explaining what is wrong. > \[1\] > {noformat} > 09:30:03,749 ERROR [org.jboss.as.ejb3.invocation] (default task-25) WFLYEJB0034: EJB Invocation failed on component SecuredEjb for method public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText() of bean: SecuredEjb is not allowed > at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74) > at org.jboss.qa.management.web.resources.SecuredEjb$$$view6.securedText(Unknown Source) > at org.jboss.qa.management.web.resources.ServletWithSecuredEjb.doGet(ServletWithSecuredEjb.java:27) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$0(ElytronRunAsHandler.java:56) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:395) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:188) > at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:55) > at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7283) Update EJB to use txn spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7283: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Update EJB to use txn spi > ------------------------- > > Key: WFLY-7283 > URL: https://issues.jboss.org/browse/WFLY-7283 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Minor > Fix For: 10.2.0.Final, 11.0.0.Beta1 > > > Remote references from EJB to internal transaction classes, replacing then by references to the spi. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:07 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7235: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > InfinispanResourceRefTestCase fails with security manager > --------------------------------------------------------- > > Key: WFLY-7235 > URL: https://issues.jboss.org/browse/WFLY-7235 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ingo Weiss > Fix For: 11.0.0.Beta1 > > > *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}} > {code} > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442) > at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127) > at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163) > at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319) > at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313) > at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810) > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213) > at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163) > at org.infinispan.factories.ComponentRegistry.(ComponentRegistry.java:79) > ... 210 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7116) High CPU usage during high concurrency of distributed @Stateful EJB creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7116: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > High CPU usage during high concurrency of distributed @Stateful EJB creation > ---------------------------------------------------------------------------- > > Key: WFLY-7116 > URL: https://issues.jboss.org/browse/WFLY-7116 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Replace usage of KeyAffinityService with AffinityTaggedKey. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7119) Introduce new web session granularity for consistent fine granularity replication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7119: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Introduce new web session granularity for consistent fine granularity replication > --------------------------------------------------------------------------------- > > Key: WFLY-7119 > URL: https://issues.jboss.org/browse/WFLY-7119 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently, ATTRIBUTE granularity sessions are vulnerable to partial stale reads, where some session attributes might have current data, and some are stale. For some use cases, this might be intolerable. For these use cases, we should introduce a new session granularity that tracks a version or checksum per attribute, that we can use to detect stale attribute cache entries. > This new granularity would retain the performance benefits of ATTRIBUTE granularity replication while maintaining the attribute consistency guarantees of SESSION granularity replication. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6973) Upgrade Infinispan to 9.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6973: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Upgrade Infinispan to 9.0 > ------------------------- > > Key: WFLY-6973 > URL: https://issues.jboss.org/browse/WFLY-6973 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: No Release > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7100) Add JGroups-based SingletonServiceBuilderFactory implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7100: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add JGroups-based SingletonServiceBuilderFactory implementation > --------------------------------------------------------------- > > Key: WFLY-7100 > URL: https://issues.jboss.org/browse/WFLY-7100 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > The singleton subsystem currently requires the Infinispan subsystem. To minimize the requirements for using the singleton subsystem within the context of the host-controller, we should reimplement singleton service using JGroups directly, instead of requiring an Infinispan cache. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7117) High CPU usage during high concurrency of distributed SSO creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7117: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > High CPU usage during high concurrency of distributed SSO creation > ------------------------------------------------------------------ > > Key: WFLY-7117 > URL: https://issues.jboss.org/browse/WFLY-7117 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Replace usage of KeyAffinityService with AffinityTaggedKey. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6823: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6958) Use more intuitive values for consistent-hash-strategy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6958: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Use more intuitive values for consistent-hash-strategy > ------------------------------------------------------ > > Key: WFLY-6958 > URL: https://issues.jboss.org/browse/WFLY-6958 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently consistent-hash-strategy can have on of 2 values: INTRA_CACHE vs INTER_CACHE. > This was initially meant to describe a consistent hash that would be consistent within a cache vs across multiple caches within a cache container. In retrospect, these value are not very descriptive. > Better would be consistent-hash-strategy="AGE|ADDRESS" or "AGE|NAME", where the strategy uses the cache view sorted by either age, or name/address. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6900) ConnectionListenerTestCase.testConnListenerTest doesn't clean up properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6900: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > ConnectionListenerTestCase.testConnListenerTest doesn't clean up properly > ------------------------------------------------------------------------- > > Key: WFLY-6900 > URL: https://issues.jboss.org/browse/WFLY-6900 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 11.0.0.Beta1 > > > The method is called twice with different deployment names as a param, but the cleanup logic in the finally block hard codes one of the names, leading to log noise in later tests as the leftover deployment fails to deploy. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7115) High CPU usage during high concurrency of distributed web session creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7115: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > High CPU usage during high concurrency of distributed web session creation > -------------------------------------------------------------------------- > > Key: WFLY-7115 > URL: https://issues.jboss.org/browse/WFLY-7115 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Replace usage of KeyAffinityService with AffinityTaggedKey. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7041) Add testing for Web -> EJB Identity Propagation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7041: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add testing for Web -> EJB Identity Propagation > ----------------------------------------------- > > Key: WFLY-7041 > URL: https://issues.jboss.org/browse/WFLY-7041 > Project: WildFly > Issue Type: Task > Components: EJB, Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Labels: elytron_testing > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:08 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:08 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7040) Add a set of tests for HTTP authentication when backed by Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-7040: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add a set of tests for HTTP authentication when backed by Elytron > ----------------------------------------------------------------- > > Key: WFLY-7040 > URL: https://issues.jboss.org/browse/WFLY-7040 > Project: WildFly > Issue Type: Task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Labels: elytron_testing > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6778) Each Undertow server should expose a distinct SessionIdentifierCodec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6778: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Each Undertow server should expose a distinct SessionIdentifierCodec > -------------------------------------------------------------------- > > Key: WFLY-6778 > URL: https://issues.jboss.org/browse/WFLY-6778 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Undertow exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. > Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. Thus, rather than installing a single SessionIdentifierCodec for the subsystem, we should install one instance per server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6498: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > EJBClient UserTransactions with multiple method invocations generate lock conflicts > ------------------------------------------------------------------------------------ > > Key: WFLY-6498 > URL: https://issues.jboss.org/browse/WFLY-6498 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Using the EJBClient library, we should be able to do the following from a standalone EJBClient application: > // create a UserTransaction associated with a clustered server node X > // make an invocation on an EJB on X > // make an invocation on an EJB on X > // commit the UserTransaction > However, doing so results in this exception which occurs during processing of the second invocation: > {noformat} > 11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction::120:local. Lock is held by GlobalTransaction::118:local > at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113) > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176) > at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411) > at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443) > at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286) > at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87) > at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49) > at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244) > at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > {noformat} > The exception does not arise if we perform only one invocation within the UserTransaction. > This exception is repeatable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6779) Add WISE for Web console access In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6779: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add WISE for Web console access > ------------------------------- > > Key: WFLY-6779 > URL: https://issues.jboss.org/browse/WFLY-6779 > Project: WildFly > Issue Type: Feature Request > Components: Web Console > Reporter: R Searls > Assignee: R Searls > Priority: Minor > Fix For: 11.0.0.Beta1 > > > Wise is a Java framework for easily invoking webservices, which can be used as base for zero-code webservice invocation applications. (see http://wise.jboss.org/) > Based upon Brian Stansberry's advise WISE is added to wfly using the "Mixed-Approach" > for adding a feature. > Once this is available in wfly. HAL can provide a link to it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6616: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Problems in DomainHostExcludes700TestCase > ----------------------------------------- > > Key: WFLY-6616 > URL: https://issues.jboss.org/browse/WFLY-6616 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > Labels: domain-mode > Fix For: 11.0.0.Beta1 > > > The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message: > {code} > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."}, > "rolled-back" => true > } > {code} > And we also see an error in > {code} > DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1> > {code} > Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6395) Elytron integration with JGroups Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6395: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Elytron integration with JGroups Subsystem > ------------------------------------------ > > Key: WFLY-6395 > URL: https://issues.jboss.org/browse/WFLY-6395 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Darran Lofthouse > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6396) Elytron integration with the mail subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6396: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Elytron integration with the mail subsystem > ------------------------------------------- > > Key: WFLY-6396 > URL: https://issues.jboss.org/browse/WFLY-6396 > Project: WildFly > Issue Type: Feature Request > Components: Mail > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:09 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:09 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6732) IllegalStateException in ApplicationSecurityDomainService#initialSecurityHandler when loginConfig is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6732: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > IllegalStateException in ApplicationSecurityDomainService#initialSecurityHandler when loginConfig is null > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-6732 > URL: https://issues.jboss.org/browse/WFLY-6732 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Farah Juma > Assignee: Farah Juma > Labels: affects_elytron > Fix For: 11.0.0.Beta1 > > > The following IllegalStateException occurs when attempting to deploy an application that doesn't specify the {{login-config}}: > {code} > java.lang.IllegalStateException: WFLYUT0084: No authentication mechanisms have been selected. > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345) > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:295) > at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:400) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:204) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5776) Make use of the principals to roles map as defined within web deployments. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5776: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Make use of the principals to roles map as defined within web deployments. > -------------------------------------------------------------------------- > > Key: WFLY-5776 > URL: https://issues.jboss.org/browse/WFLY-5776 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 11.0.0.Beta1 > > > Will follow up on this one after the authentication is handled. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6365) Update permissions to use Elytron permission helper API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6365: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Update permissions to use Elytron permission helper API > ------------------------------------------------------- > > Key: WFLY-6365 > URL: https://issues.jboss.org/browse/WFLY-6365 > Project: WildFly > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 11.0.0.Beta1 > > > The Elytron permission base classes ensure spec compliance including serialization guarantees while also drastically reducing the amount of code required to implement permission classes correctly and improving performance and memory overhead, especially when a security manager is engaged. Use these classes as base classes for all WildFly permission classes. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5660) Add metrics for Infinispan thread pools In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5660: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add metrics for Infinispan thread pools > --------------------------------------- > > Key: WFLY-5660 > URL: https://issues.jboss.org/browse/WFLY-5660 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 11.0.0.Beta1 > > > Now that we have thread pool resources, we should expose metrics to expose things like active thread count, queue size, etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5685) Register management resources for deployment-specific caches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5685: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Register management resources for deployment-specific caches > ------------------------------------------------------------ > > Key: WFLY-5685 > URL: https://issues.jboss.org/browse/WFLY-5685 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5976) Upgrade Artemis 1.2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5976: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Upgrade Artemis 1.2.0 > --------------------- > > Key: WFLY-5976 > URL: https://issues.jboss.org/browse/WFLY-5976 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6085) Wrong AdvancedADLdap mapping in ModulesMap In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-6085: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Wrong AdvancedADLdap mapping in ModulesMap > ------------------------------------------ > > Key: WFLY-6085 > URL: https://issues.jboss.org/browse/WFLY-6085 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > There is wrong AdvancedADLdap mapping in ModulesMap. > In ModulesMap is "AdvancedAdLdap", but in documentation is "AdvancedADLdap". > https://github.com/jbossas/jboss-eap7/blob/7.x/security/subsystem/src/main/java/org/jboss/as/security/ModulesMap.java#L105 > https://access.stage.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0.beta/login-module-reference/#advancedadldap_login_module > We suggest some like this for backward compatibility: > Add one extra mapping to ModulesMap with right mapping and leave there old mapping too. Some old app can use this old wrong mapping. > {code} > put("AdvancedAdLdap", AdvancedADLoginModule.class.getName()); > put("AdvancedADLdap", AdvancedADLoginModule.class.getName()); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:10 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:10 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5603) Get data source information In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5603: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Get data source information > --------------------------- > > Key: WFLY-5603 > URL: https://issues.jboss.org/browse/WFLY-5603 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Jesper Pedersen > Assignee: Lin Gao > Fix For: 11.0.0.Beta1 > > > Create a DMR operation that returns the available properties for the data source class, and xa data source class for the -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:11 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:11 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5551) Formalize ejb clustering modules into a proper subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5551: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Formalize ejb clustering modules into a proper subsystem > -------------------------------------------------------- > > Key: WFLY-5551 > URL: https://issues.jboss.org/browse/WFLY-5551 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.CR3 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently, the coupling between the ejb3 subsystem and the modules required for the distributed cache is very loose. > Consequently, misconfiguration (e.g. a missing "ejb" cache-container) can prevent deployment from succeeding without an adequate explanation. > The subsystem would define the requisite cache-container, exposed as a capability. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:11 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:11 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5535) Create an OGM integration adapter so that OGM works better on WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5535: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Create an OGM integration adapter so that OGM works better on WildFly > --------------------------------------------------------------------- > > Key: WFLY-5535 > URL: https://issues.jboss.org/browse/WFLY-5535 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Beta1 > > > OGM needs to use the same integration on WildFly as Hibernate ORM uses. As an implementation detail, the OGM integration will extend the ORM integration, so that OGM gets bug fixes automatically and also shows hibernate (ORM) statistics in the WildFly console. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:11 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:11 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5550) Formalize web session clustering modules into a proper subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5550: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Formalize web session clustering modules into a proper subsystem > ---------------------------------------------------------------- > > Key: WFLY-5550 > URL: https://issues.jboss.org/browse/WFLY-5550 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.CR3 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently, the coupling between the undertow subsystem and the modules required for distributed web session manager and single sign-on manager support is very loose. > Consequently, misconfiguration (e.g. a missing "web" cache-container) can prevent deployment from succeeding without an adequate explanation. > The subsystem would define the requisite cache-container, exposed as a capability. > This subsystem would exposes a number of profiles, containing the configuration traditionally specified in jboss-web.xml, as well as the cache configuration to use (specified by cache-container + cache name). jboss-web.xml would only need to reference a profile by name, or, if unspecified, use the default profile. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:11 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:11 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5497) Add to shared-session-config schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5497: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Add to shared-session-config schema > ---------------------------------------------------- > > Key: WFLY-5497 > URL: https://issues.jboss.org/browse/WFLY-5497 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.CR2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently, the shared-session-config does not indicate whether a distributable or non-distributable session manager should be used. Consequently, we assign the session manager implementation based on the availability of the module providing the distributed implementation. Since the default infinispan web session configuration attempts to passivate sessions on shutdown, users will see NotSerializableExceptions on shutdown if they use non-serializable session attributes - even if their web applications do not define themselves as being . > To clarify this ambiguity, we should add a element (a la web.xml) to the shared-session-config schema to determine which session manager implementation to use. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:11 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:11 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5265) Use WildFly Common for null param checks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-5265: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Use WildFly Common for null param checks > ---------------------------------------- > > Key: WFLY-5265 > URL: https://issues.jboss.org/browse/WFLY-5265 > Project: WildFly > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > Fix For: 11.0.0.Beta1 > > > For each module, do the following: > * Locate any/all null param check methods in the log msg > * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed > * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:11 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:11 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4934) Make use of the new capabilities API in mod_cluster extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-4934: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Make use of the new capabilities API in mod_cluster extension > ------------------------------------------------------------- > > Key: WFLY-4934 > URL: https://issues.jboss.org/browse/WFLY-4934 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Alpha5 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Beta1 > > > This is currently about depending on socket-bindings. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:14 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:14 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-487) Verify audit implications and required APIs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-487: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Verify audit implications and required APIs > ------------------------------------------- > > Key: WFLY-487 > URL: https://issues.jboss.org/browse/WFLY-487 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 11.0.0.Beta1 > > > Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected. > i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:13 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:13 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-1598: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Out of the box SSL - or shortly after. > -------------------------------------- > > Key: WFLY-1598 > URL: https://issues.jboss.org/browse/WFLY-1598 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Labels: management_security,, management_sso > Fix For: 11.0.0.Beta1 > > > There are various reasons that we do not support SSL/TLS out of the box e.g. > - If we ship a default keystore then everyone has access to the private key. > - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead. > This issue is to explorer other options to encourage their use and make it easier to configure. > As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:14 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:14 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-447) Connection Reauthentication and Security Propagation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-447: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Connection Reauthentication and Security Propagation > ---------------------------------------------------- > > Key: WFLY-447 > URL: https://issues.jboss.org/browse/WFLY-447 > Project: WildFly > Issue Type: Task > Components: EJB, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 11.0.0.Beta1 > > > This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting. > This is to predominantly cover two major scenarios: - > - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user. > - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as. > The following document is building up the requirements and design considerations and decisions: - > https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPropagation -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:14 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:14 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-442: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Review of AccessController and PrivilegedAction use across AS7 > -------------------------------------------------------------- > > Key: WFLY-442 > URL: https://issues.jboss.org/browse/WFLY-442 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: investigation_required > Fix For: 11.0.0.Beta1 > > > The following needs reviewing across AS7: - > - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable). > - Use of AccessController even though there is no SecurityManager set. > - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED > - Utility methods with visibility too high. > - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction. > - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:14 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:14 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-421) Domain Mode JMX access through the HostController In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-421: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Domain Mode JMX access through the HostController > ------------------------------------------------- > > Key: WFLY-421 > URL: https://issues.jboss.org/browse/WFLY-421 > Project: WildFly > Issue Type: Task > Components: JMX, Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: JMX, investigation_required > Fix For: 11.0.0.Beta1 > > > This task is first to review if this should be considered. > At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy. > The main motivation being to separate management and app traffic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:15 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:15 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-383: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase > ----------------------------------------------------------------- > > Key: WFLY-383 > URL: https://issues.jboss.org/browse/WFLY-383 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid. > I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:40:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 17:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2584) Domain Mode JMX access through the HostController In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-421 to WFCORE-2584: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2584 (was: WFLY-421) Issue Type: Feature Request (was: Task) Component/s: Domain Management JMX Remoting (was: JMX) (was: Remoting) Fix Version/s: (was: 11.0.0.Beta1) > Domain Mode JMX access through the HostController > ------------------------------------------------- > > Key: WFCORE-2584 > URL: https://issues.jboss.org/browse/WFCORE-2584 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, JMX, Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: JMX, investigation_required > > This task is first to review if this should be considered. > At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy. > The main motivation being to separate management and app traffic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:41:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 27 Mar 2017 17:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7564) EJB Attachment protocol mismatch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd resolved WFLY-7564. ------------------------------- Resolution: Done > EJB Attachment protocol mismatch > -------------------------------- > > Key: WFLY-7564 > URL: https://issues.jboss.org/browse/WFLY-7564 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good. > The fix: > * In protocol 3 and higher, always read and write a packed integer > * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present > Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:41:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 27 Mar 2017 17:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7564) EJB Attachment protocol mismatch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFLY-7564: ------------------------------ Fix Version/s: 11.0.0.Alpha1 (was: 11.0.0.Beta1) > EJB Attachment protocol mismatch > -------------------------------- > > Key: WFLY-7564 > URL: https://issues.jboss.org/browse/WFLY-7564 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good. > The fix: > * In protocol 3 and higher, always read and write a packed integer > * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present > Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:52:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 17:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2585) Servers in domain don't start if management interfaces are bound to all IPv4 addresses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-9924 to WFCORE-2585: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2585 (was: JBEAP-9924) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: 3.0.0.Beta11 (was: 7.1.0.DR15) Affects Testing: (was: Regression) > Servers in domain don't start if management interfaces are bound to all IPv4 addresses > -------------------------------------------------------------------------------------- > > Key: WFCORE-2585 > URL: https://issues.jboss.org/browse/WFCORE-2585 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Priority: Blocker > Attachments: host-controller.log, server-one.log > > > This is regression compared to EAP 7.0.0. > See attached logs server-one.log , host-controller.log > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2) MSC000001: Failed to start service jboss.server-boot-operations: org.jboss.msc.service.StartException in service jboss.server-boot-operations: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:72) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128) > at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110) > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68) > ... 4 more > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:426) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:241) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:427) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:415) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:177) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:113) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:53:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 17:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2585) Servers in domain don't start if management interfaces are bound to all IPv4 addresses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2585: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Servers in domain don't start if management interfaces are bound to all IPv4 addresses > -------------------------------------------------------------------------------------- > > Key: WFCORE-2585 > URL: https://issues.jboss.org/browse/WFCORE-2585 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.0.Beta12 > > Attachments: host-controller.log, server-one.log > > > This is regression compared to EAP 7.0.0. > See attached logs server-one.log , host-controller.log > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2) MSC000001: Failed to start service jboss.server-boot-operations: org.jboss.msc.service.StartException in service jboss.server-boot-operations: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:72) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128) > at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110) > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68) > ... 4 more > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:426) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:241) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:427) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:415) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:177) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:113) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:53:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 27 Mar 2017 17:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2585) Servers in domain don't start if management interfaces are bound to all IPv4 addresses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384830#comment-13384830 ] Brian Stansberry commented on WFCORE-2585: ------------------------------------------ I scheduled this for Beta12 just so it's always on the current release issue list, but it's a Blocker for CR1 not Beta12. > Servers in domain don't start if management interfaces are bound to all IPv4 addresses > -------------------------------------------------------------------------------------- > > Key: WFCORE-2585 > URL: https://issues.jboss.org/browse/WFCORE-2585 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.0.Beta12 > > Attachments: host-controller.log, server-one.log > > > This is regression compared to EAP 7.0.0. > See attached logs server-one.log , host-controller.log > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2) MSC000001: Failed to start service jboss.server-boot-operations: org.jboss.msc.service.StartException in service jboss.server-boot-operations: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:72) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128) > at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110) > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68) > ... 4 more > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:426) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:241) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:427) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:415) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:177) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:113) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:04:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 27 Mar 2017 19:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-149) Initializing the SyslogHandler should not do a permissions check when setting the output stream In-Reply-To: References: Message-ID: James Perkins created LOGMGR-149: ------------------------------------ Summary: Initializing the SyslogHandler should not do a permissions check when setting the output stream Key: LOGMGR-149 URL: https://issues.jboss.org/browse/LOGMGR-149 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins The {{org.jboss.logmanager.handlers.SyslogHandler}} attempts to lazily connect to the syslog server. If running under a security manager and the user (deployment in WildFly's case) doesn't have {{control}} logging permissions, the write will fail. The failure is also swallowed which means there is no indication as to what the error is. Logs will just not appear on the syslog server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:12 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:12 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-4304: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Servlet authentication kicked off when *not* a part of any security-constraint > ------------------------------------------------------------------------------ > > Key: WFLY-4304 > URL: https://issues.jboss.org/browse/WFLY-4304 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Brett Meyer > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself. > A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom: > If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:12 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:12 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4056) Graceful shutdown for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-4056: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Graceful shutdown for JMS > ------------------------- > > Key: WFLY-4056 > URL: https://issues.jboss.org/browse/WFLY-4056 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Stuart Douglas > Assignee: Jeff Mesnil > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:12 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:12 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3064) Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-3064: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case. > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-3064 > URL: https://issues.jboss.org/browse/WFLY-3064 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > A new test case was added under WFLY-3063 that demonstrates the correct way to do this so now remove the original way that depended on internal APIs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:12 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:12 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2955) Audit logging should also be able to use PKCS#11 for keystores. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-2955: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Audit logging should also be able to use PKCS#11 for keystores. > --------------------------------------------------------------- > > Key: WFLY-2955 > URL: https://issues.jboss.org/browse/WFLY-2955 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:12 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:12 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation parsing error message In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-2102: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Improve deployment annotation parsing error message > ----------------------------------------------------- > > Key: WFLY-2102 > URL: https://issues.jboss.org/browse/WFLY-2102 > Project: WildFly > Issue Type: Enhancement > Components: EE > Reporter: Brad Maxwell > Fix For: 11.0.0.Beta1 > > Attachments: test-WFLY-2102.jar > > > Improve deployment annotation parsing error message > Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env. The env is not enough information to identify what the issue is. > @Singleton > @Startup > public class TestEJB { > @Resource(name="/queue/test") > private Queue queue; > } > Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env > at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183) > at org.jboss.as.naming.deployment.ContextNames$BindInfo.(ContextNames.java:195) > at org.jboss.as.naming.deployment.ContextNames$BindInfo.(ContextNames.java:186) > at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141) > at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84) > at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019) > at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998) > at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138) > at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95) > ... 6 more -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:12 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:12 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3224) SSL The Last Round In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-3224: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > SSL The Last Round > ------------------ > > Key: WFLY-3224 > URL: https://issues.jboss.org/browse/WFLY-3224 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > I could probably list most components in the components box, anyway this is a top level task to contain all of the SSL enhancements required so that they can be addressed once and for all. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:13 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:13 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1159) Allow configure SSL connection in stanalone.xml for email servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-1159: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Allow configure SSL connection in stanalone.xml for email servers > ----------------------------------------------------------------- > > Key: WFLY-1159 > URL: https://issues.jboss.org/browse/WFLY-1159 > Project: WildFly > Issue Type: Sub-task > Components: Mail > Reporter: Alexey Volkov > Assignee: Peter Skopek > Fix For: 11.0.0.Beta1 > > > Allow to configure SSL connection to email servers into stanalone.xml > Here is the discussion into community https://community.jboss.org/thread/205364 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:13 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:13 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-1033: ------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Enhance XTS AS7 configuration > ----------------------------- > > Key: WFLY-1033 > URL: https://issues.jboss.org/browse/WFLY-1033 > Project: WildFly > Issue Type: Enhancement > Components: XTS > Reporter: Andrew Dinn > Priority: Minor > Fix For: 11.0.0.Beta1 > > > The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the element in the AS7 standalone configuration file. No other configuration options are currently supported. > XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations. > The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 17:33:14 2017 From: issues at jboss.org (Jason Greene (JIRA)) Date: Mon, 27 Mar 2017 17:33:14 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-466: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem. > -------------------------------------------------------------------------------- > > Key: WFLY-466 > URL: https://issues.jboss.org/browse/WFLY-466 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container. > This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:08:01 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 27 Mar 2017 19:08:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8456) Protocols added to a fork of some channel won't show in JMX MBeans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8456: --------------------------------- Affects Version/s: 11.0.0.Alpha1 > Protocols added to a fork of some channel won't show in JMX MBeans > ------------------------------------------------------------------ > > Key: WFLY-8456 > URL: https://issues.jboss.org/browse/WFLY-8456 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > > When defining a fork of some channel and adding a protocol to the protocol stack of that fork channel, the newly added protocol won't show up in JMX MBeans. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:38:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 27 Mar 2017 19:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2532) Some logging tests fail with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384843#comment-13384843 ] James Perkins commented on WFCORE-2532: --------------------------------------- In the pull request I added a work around for LOGMGR-149. This is a permissions error in the {{org.jboss.logmanager.handlers.SyslogHandler}}. > Some logging tests fail with security manager in WF core > -------------------------------------------------------- > > Key: WFCORE-2532 > URL: https://issues.jboss.org/browse/WFCORE-2532 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > > * *org.jboss.as.test.integration.logging.operations.CustomFormattersTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerOperationsTestCase* > * *org.jboss.as.test.integration.logging.operations.CustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.operations.Log4jCustomHandlerTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLog4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.JBossLoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jPropertiesTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.Log4jXmlTestCase* > * *org.jboss.as.test.integration.logging.perdeploy.LoggingPropertiesTestCase* > * *org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase* > * *org.jboss.as.test.integration.logging.profiles.NonExistingProfileTestCase* > * *org.jboss.as.test.integration.logging.syslog.SyslogHandlerTestCase* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=org.jboss.as.test.integration.logging.**.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging1.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging1.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging1.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging1.jar )\" of \"ModuleClassLoader for Module \"deployment.logging1.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging1.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.test.integration.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:168) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:314) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.deploy(LoggingProfilesTestCase.java:304) > at org.jboss.as.test.integration.logging.profiles.LoggingProfilesTestCase.testProfiles(LoggingProfilesTestCase.java:201 > {code} > * *org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase* > * *org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase* > * *org.jboss.as.test.manualmode.logging.PerDeployLoggingTestCase* > * *org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase* > * *org.jboss.as.test.manualmode.logging.SizeAppenderRestartTestCase* > * *org.jboss.as.test.manualmode.logging.SyslogIsNotAvailableDuringServerBootTestCase* > {{cd testsuite/manualmode/}} > {{mvn test -Dtest=org.jboss.as.test.manualmode.logging.* -Dsecurity.manager}} > {code} > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"logging-test.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"logging-test.jar\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"logging-test.jar\" > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"jboss.bind.address\" \"read\")\" in code source \"(vfs:/content/logging-test.jar )\" of \"ModuleClassLoader for Module \"deployment.logging-test.jar\" from Service Module Loader\")"}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"logging-test.jar\".INSTALL"] > } > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.wildfly.core.testrunner.ServerController.deploy(ServerController.java:92) > at org.jboss.as.test.manualmode.logging.AbstractLoggingTestCase.deploy(AbstractLoggingTestCase.java:197) > at org.jboss.as.test.manualmode.logging.Log4jAppenderTestCase.startContainer(Log4jAppenderTestCase.java:93) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:55:01 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 27 Mar 2017 19:55:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-149) Initializing the SyslogHandler should not do a permissions check when setting the output stream In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-149: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/107, https://github.com/jboss-logging/jboss-logmanager/pull/108 (was: https://github.com/jboss-logging/jboss-logmanager/pull/107) > Initializing the SyslogHandler should not do a permissions check when setting the output stream > ----------------------------------------------------------------------------------------------- > > Key: LOGMGR-149 > URL: https://issues.jboss.org/browse/LOGMGR-149 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > > The {{org.jboss.logmanager.handlers.SyslogHandler}} attempts to lazily connect to the syslog server. If running under a security manager and the user (deployment in WildFly's case) doesn't have {{control}} logging permissions, the write will fail. The failure is also swallowed which means there is no indication as to what the error is. Logs will just not appear on the syslog server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:57:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 27 Mar 2017 19:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-149) Initializing the SyslogHandler should not do a permissions check when setting the output stream In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-149: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/107, https://github.com/jboss-logging/jboss-logmanager/pull/108, https://github.com/jboss-logging/jboss-logmanager/pull/109 (was: https://github.com/jboss-logging/jboss-logmanager/pull/107, https://github.com/jboss-logging/jboss-logmanager/pull/108) > Initializing the SyslogHandler should not do a permissions check when setting the output stream > ----------------------------------------------------------------------------------------------- > > Key: LOGMGR-149 > URL: https://issues.jboss.org/browse/LOGMGR-149 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Fix For: 1.5.8.Final, 2.0.7.Final, 2.1.0.Beta1 > > > The {{org.jboss.logmanager.handlers.SyslogHandler}} attempts to lazily connect to the syslog server. If running under a security manager and the user (deployment in WildFly's case) doesn't have {{control}} logging permissions, the write will fail. The failure is also swallowed which means there is no indication as to what the error is. Logs will just not appear on the syslog server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:57:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 27 Mar 2017 19:57:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-149) Initializing the SyslogHandler should not do a permissions check when setting the output stream In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated LOGMGR-149: --------------------------------- Fix Version/s: 1.5.8.Final 2.0.7.Final 2.1.0.Beta1 > Initializing the SyslogHandler should not do a permissions check when setting the output stream > ----------------------------------------------------------------------------------------------- > > Key: LOGMGR-149 > URL: https://issues.jboss.org/browse/LOGMGR-149 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Fix For: 1.5.8.Final, 2.0.7.Final, 2.1.0.Beta1 > > > The {{org.jboss.logmanager.handlers.SyslogHandler}} attempts to lazily connect to the syslog server. If running under a security manager and the user (deployment in WildFly's case) doesn't have {{control}} logging permissions, the write will fail. The failure is also swallowed which means there is no indication as to what the error is. Logs will just not appear on the syslog server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 19:08:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Mon, 27 Mar 2017 19:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8456) Protocols added to a fork of some channel won't show in JMX MBeans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-9925 to WFLY-8456: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8456 (was: JBEAP-9925) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: (was: 7.1.0.DR13) > Protocols added to a fork of some channel won't show in JMX MBeans > ------------------------------------------------------------------ > > Key: WFLY-8456 > URL: https://issues.jboss.org/browse/WFLY-8456 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > > When defining a fork of some channel and adding a protocol to the protocol stack of that fork channel, the newly added protocol won't show up in JMX MBeans. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 21:12:00 2017 From: issues at jboss.org (=?UTF-8?Q?=E5=9B=BD=E4=BC=9F_=E6=9C=B1_=28JIRA=29?=) Date: Mon, 27 Mar 2017 21:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1499) When concurrently get prototype ksession bean, it could be repeated In-Reply-To: References: Message-ID: ?? ? created DROOLS-1499: ---------------------------- Summary: When concurrently get prototype ksession bean, it could be repeated Key: DROOLS-1499 URL: https://issues.jboss.org/browse/DROOLS-1499 Project: Drools Issue Type: Bug Components: integration Affects Versions: 6.5.0.Final Reporter: ?? ? Assignee: Mario Fusco when currently get ksession bean , there could be repeated ksessions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 21:38:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 27 Mar 2017 21:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7337) Introduce an authorization SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng closed WFLY-7337. --------------------------- Resolution: Won't Do > Introduce an authorization SPI > ------------------------------ > > Key: WFLY-7337 > URL: https://issues.jboss.org/browse/WFLY-7337 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 02:36:00 2017 From: issues at jboss.org (Jan Martiska (JIRA)) Date: Tue, 28 Mar 2017 02:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2586) JmxControlledStateNotificationsInStaticModuleTestCase intermittently fails on IBM jdk In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Martiska moved JBEAP-9929 to WFCORE-2586: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2586 (was: JBEAP-9929) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.1.0.DR15) > JmxControlledStateNotificationsInStaticModuleTestCase intermittently fails on IBM jdk > ------------------------------------------------------------------------------------- > > Key: WFCORE-2586 > URL: https://issues.jboss.org/browse/WFCORE-2586 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Martiska > Assignee: Jan Martiska > > Some intermittent failures in: > org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsInStaticModuleTestCase > org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase > can be seen running wildfly-core integration testsuite on IBM jvm. > see https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-test-core-rhel/78/testReport/ for results of DR15 runs. > e.g. > _org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase.checkNotifications_startReloadStop_ > *Error Details* > {noformat} > jmx.attribute.change 2 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 13 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 16 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'ok' to 'stopping' expected:<4> but was:<3> > {noformat} > *Stack Trace* > {noformat} > java.lang.AssertionError: jmx.attribute.change 2 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 13 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'starting' to 'ok', jmx.attribute.change 16 jboss.root:type=state The attribute 'RuntimeConfigurationState' has changed from 'ok' to 'stopping' expected:<4> but was:<3> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase.lambda$checkFacadeJmxNotifications$0(JmxControlledStateNotificationsTestCase.java:175) > {noformat} > *Standard Output snippet* > {noformat} > &#27;[0m&#27;[0m14:18:42,096 INFO [org.jboss.as.server] (ServerService Thread Pool -- 7) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m14:18:42,232 INFO [org.jboss.as.protocol] (management I/O-1) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 3,5,management-handler-thread] > &#27;[0m&#27;[31m14:18:42,240 ERROR [org.wildfly.test.jmx.ControlledStateNotificationListener] (management-handler-thread - 3) Problem handling JMX Notification: java.nio.channels.ClosedByInterruptException > at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:220) > at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:228) > at java.nio.channels.Channels.writeFullyImpl(Channels.java:89) > at java.nio.channels.Channels.writeFully(Channels.java:112) > at java.nio.channels.Channels.access$000(Channels.java:72) > at java.nio.channels.Channels$1.write(Channels.java:185) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:303) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:307) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:287) > at java.io.BufferedWriter.flush(BufferedWriter.java:265) > at org.wildfly.test.jmx.ControlledStateNotificationListener.writeNotification(ControlledStateNotificationListener.java:84) > at org.wildfly.test.jmx.ControlledStateNotificationListener.handleNotification(ControlledStateNotificationListener.java:74) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1766) > at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:286) > at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:363) > at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:348) > at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:259) > at org.jboss.as.server.jmx.RunningStateJmx.setProcessState(RunningStateJmx.java:112) > at org.jboss.as.server.jmx.RunningStateJmx.lambda$registerStateListener$0(RunningStateJmx.java:212) > at org.jboss.as.server.jmx.RunningStateJmx$$Lambda$46.0000000040DD2A40.propertyChange(Unknown Source) > at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:346) > at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:338) > at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:274) > at org.jboss.as.controller.ControlledProcessStateService.stateChanged(ControlledProcessStateService.java:105) > at org.jboss.as.controller.ControlledProcessState.setStopping(ControlledProcessState.java:127) > at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.listenerAdded(ProcessReloadHandler.java:82) > at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1537) > at org.jboss.msc.service.ServiceControllerImpl.addListener(ServiceControllerImpl.java:1254) > at org.jboss.as.controller.OperationContextImpl$OperationContextServiceController.addListener(OperationContextImpl.java:2449) > at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1.handleResult(ProcessReloadHandler.java:79) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1493) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1475) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1437) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1410) > at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1284) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:856) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:842) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:748) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.jboss.as.controller.ModelControllerImpl$$Lambda$193.00000000E0015CC0.run(Unknown Source) > at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$194.00000000E00163C0.run(Unknown Source) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$192.00000000E000FE80.run(Unknown Source) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} > The tests were introduced just recently as a coverage for EAP7-471. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 02:56:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 28 Mar 2017 02:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1536) NPE thrown during application redeployment, slaves taken offline In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384897#comment-13384897 ] RH Bugzilla Integration commented on WFCORE-1536: ------------------------------------------------- Radovan Netuka changed the Status of [bug 1406562|https://bugzilla.redhat.com/show_bug.cgi?id=1406562] from ASSIGNED to POST > NPE thrown during application redeployment, slaves taken offline > ---------------------------------------------------------------- > > Key: WFCORE-1536 > URL: https://issues.jboss.org/browse/WFCORE-1536 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Matthew Casperson > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha2 > > > We have some development Wildfly 10.0.0 servers running as slaves in a domain that frequently have WAR files redeployed. We have noticed that these slaves will often go offline after a redeployment of WAR files with the following stack trace: > {code} > 2016-05-06 05:05:51,306 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 1012) WFLYCTL0190: Step handler org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler at 3f68226b for operation {"operation" => "full-replace-deployment","name" => "whatever.war","enabled" => true,"content" => [{"hash" => bytes { 0x5d, 0x12, 0x18, 0x2b, 0x1c, 0x86, 0x71, 0x27, 0x08, 0x3d, 0xf1, 0x75, 0x08, 0x29, 0xa6, 0x49, 0x1f, 0x16, 0xe8, 0x22 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "802ab616-dd2c-4081-a79c-c4d54e14c384","push-to-servers" => undefined},"address" => [],"runtime-name" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException > at org.jboss.as.repository.LocalDeploymentFileRepository.deleteDeployment(LocalDeploymentFileRepository.java:59) > at org.jboss.as.host.controller.RemoteDomainConnectionService$RemoteFileRepository.deleteDeployment(RemoteDomainConnectionService.java:756) > at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler$1.handleResult(DeploymentFullReplaceHandler.java:181) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311) > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:360) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > This error will usually only happen for 2 out of the 4 identically configured slaves, and seems to happen randomly, although frequently enough. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:05:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 28 Mar 2017 03:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1035) CS tool, Error msg with mutually exclusive parameters must contain "really" used option names. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1035: --------------------------------- Summary: CS tool, Error msg with mutually exclusive parameters must contain "really" used option names. Key: ELY-1035 URL: https://issues.jboss.org/browse/ELY-1035 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse When we use more mutually exclusive parameters (add, remove) then we get error message. But this message contains only short version of option names. "r" instead of "remove" "a" instead of "add" {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230 --remove The option 'r' was specified but an option from this group has already been selected: 'a' {code} *Same for "credential-store" command.* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:17:01 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 28 Mar 2017 03:17:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1036) CS tool, There is possibility define same option parameter more times. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1036: --------------------------------- Summary: CS tool, There is possibility define same option parameter more times. Key: ELY-1036 URL: https://issues.jboss.org/browse/ELY-1036 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse There is possibility define same option parameter more times. It doesn't matter if some short/long form or combination there is used first occurrence in command. Command with two option "add" and "secret". {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230 --add alias2 --secret secretValue2 Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230"}) {code} *Same for "mask" command.* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:29:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Tue, 28 Mar 2017 03:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8457) TimerService.getTimers() does not return persisted timers in @PreDestroy method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss moved JBEAP-9933 to WFLY-8457: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8457 (was: JBEAP-9933) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: 11.0.0.Alpha1 (was: 7.0.4.GA) > TimerService.getTimers() does not return persisted timers in @PreDestroy method > ------------------------------------------------------------------------------- > > Key: WFLY-8457 > URL: https://issues.jboss.org/browse/WFLY-8457 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Alpha1 > Environment: JBoss EAP 7.x > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Attachments: TimerBean.java, TimerServiceEJBBug.jar > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Injecting the TimerService with an @Resource annotation > {quote} > @Resource > private TimerService timerService; > {quote} > When I call timerService.getTimers().size() in the @PreDestroy method, it always return 0. > If I deploy the same application in jboss eap 6, then timerService.getTimers().size() return 1. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:30:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Tue, 28 Mar 2017 03:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8457) TimerService.getTimers() does not return persisted timers in @PreDestroy method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8457: ----------------------------- Environment: (was: JBoss EAP 7.x) > TimerService.getTimers() does not return persisted timers in @PreDestroy method > ------------------------------------------------------------------------------- > > Key: WFLY-8457 > URL: https://issues.jboss.org/browse/WFLY-8457 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Alpha1 > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Attachments: TimerBean.java, TimerServiceEJBBug.jar > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Injecting the TimerService with an @Resource annotation > {quote} > @Resource > private TimerService timerService; > {quote} > When I call timerService.getTimers().size() in the @PreDestroy method, it always return 0. > If I deploy the same application in jboss eap 6, then timerService.getTimers().size() return 1. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:44:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 28 Mar 2017 03:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1037: --------------------------------- Summary: CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). Key: ELY-1037 URL: https://issues.jboss.org/browse/ELY-1037 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Without --location parameter a credential store storage file isn't saved (or save as is expected). {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) {code} It pass with this URI value. {code} uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" {code} I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 (test.store is interpreded as hostname in URI in first case) *NOTE* Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. Behaviour must be consistent! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:48:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 28 Mar 2017 03:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1037: ------------------------------ Description: Without --location parameter a credential store storage file isn't saved (or save as is expected). {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) {code} It pass with this URI value and I am able to find credential store storage file on disk. {code} uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" {code} I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 (test.store is interpreded as hostname in URI in first case) *NOTE* Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. Behaviour must be consistent! was: Without --location parameter a credential store storage file isn't saved (or save as is expected). {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) {code} It pass with this URI value. {code} uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" {code} I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 (test.store is interpreded as hostname in URI in first case) *NOTE* Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. Behaviour must be consistent! > CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1037 > URL: https://issues.jboss.org/browse/ELY-1037 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Without --location parameter a credential store storage file isn't saved (or save as is expected). > {code} > [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > It pass with this URI value and I am able to find credential store storage file on disk. > {code} > uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" > {code} > I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 > (test.store is interpreded as hostname in URI in first case) > *NOTE* > Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. > Behaviour must be consistent! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 03:50:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Tue, 28 Mar 2017 03:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1037: ------------------------------ Description: Without --location parameter a credential store storage file isn't saved (or save as is expected). It pass but I am not able find credential store storage file on disk. {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) {code} It pass with this URI value and I am able to find credential store storage file on disk. {code} uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" {code} I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 (test.store is interpreded as hostname in URI in first case) *NOTE* Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. Behaviour must be consistent! was: Without --location parameter a credential store storage file isn't saved (or save as is expected). {code} [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary Alias "myalias" has been successfully stored Credential store command summary: -------------------------------------- /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) {code} It pass with this URI value and I am able to find credential store storage file on disk. {code} uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" {code} I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 (test.store is interpreded as hostname in URI in first case) *NOTE* Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. Behaviour must be consistent! > CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1037 > URL: https://issues.jboss.org/browse/ELY-1037 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > > Without --location parameter a credential store storage file isn't saved (or save as is expected). > It pass but I am not able find credential store storage file on disk. > {code} > [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > It pass with this URI value and I am able to find credential store storage file on disk. > {code} > uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" > {code} > I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 > (test.store is interpreded as hostname in URI in first case) > *NOTE* > Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. > Behaviour must be consistent! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 04:17:00 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Tue, 28 Mar 2017 04:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2421) CS tool generated different MASKED password then vault.sh In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Skopek reassigned WFCORE-2421: ------------------------------------ Fix Version/s: 3.0.0.Beta12 Assignee: Peter Skopek (was: Darran Lofthouse) Resolution: Done > CS tool generated different MASKED password then vault.sh > --------------------------------------------------------- > > Key: WFCORE-2421 > URL: https://issues.jboss.org/browse/WFCORE-2421 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Fix For: 3.0.0.Beta12 > > > CS tool generated different MASKED password then vault.sh > When I run oldf vault.sh > {code} > ./vault.sh --keystore key.store --keystore-password secret_password --alias Vault --vault-block vaultBlock --attribute passDB --sec-attr secretvalue --enc-dir ./vault --iteration 230 --salt 12345678 -t > {code} > I can see this *MASK-1GhfMaq4jSY0.kFFU3QG4T* > Whole output: > {code:collapse=true} > > > > > > > > > {code} > In the other hand when I run new CS tool with params: > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret secretpassword --location="test.store1" --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password secret_password --summary --salt 12345678 --iteration 230 --create > {code} > I get *MASK-KAwLfD1BN8WFhZptWsa17G* > Whole output: > {code:collapse=true} > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-KAwLfD1BN8WFhZptWsa17G==;12345678;230"}) > {code} > *I set these values for both:* > password to mask *secret_password* > iteration *12345678* > salt *230* -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 04:39:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Tue, 28 Mar 2017 04:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) [GSS](7.1.0) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chao Wang moved JBEAP-9936 to WFLY-8458: ---------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8458 (was: JBEAP-9936) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMX Server (was: Server) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR14) > [GSS](7.1.0) NPE when MBean does not have no-arg constructor > ------------------------------------------------------------ > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 04:40:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Tue, 28 Mar 2017 04:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chao Wang updated WFLY-8458: ---------------------------- Summary: NPE when MBean does not have no-arg constructor (was: [GSS](7.1.0) NPE when MBean does not have no-arg constructor) > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 04:53:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 28 Mar 2017 04:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8450) Make org.wildfly.transaction.client module unsupported In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reopened WFLY-8450: ----------------------------------- > Make org.wildfly.transaction.client module unsupported > ------------------------------------------------------ > > Key: WFLY-8450 > URL: https://issues.jboss.org/browse/WFLY-8450 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > Per e-mail discussion with David, the {{org.wildfly.transaction.client}} module currently doesn't contain anything meant to be used by application developers directly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 04:54:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 28 Mar 2017 04:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8450) Make org.wildfly.transaction.client module unsupported In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka closed WFLY-8450. --------------------------------- Resolution: Rejected The wfly client api should be unsupported only for EAP 7. No such thing is relevant for upstream. > Make org.wildfly.transaction.client module unsupported > ------------------------------------------------------ > > Key: WFLY-8450 > URL: https://issues.jboss.org/browse/WFLY-8450 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > Per e-mail discussion with David, the {{org.wildfly.transaction.client}} module currently doesn't contain anything meant to be used by application developers directly. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 04:56:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Tue, 28 Mar 2017 04:56:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384974#comment-13384974 ] Chao Wang commented on WFLY-8458: --------------------------------- At [ParsedServiceDeploymentProcessor.java|https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/sar/src/main/java/org/jboss/as/service/ParsedServiceDeploymentProcessor.java#L282], we can add NPE check as: {code:ParsedServiceDeploymentProcessor.java} final Constructor constructor = mBeanClassHierarchy.get(0).getConstructor(types); + if(constructor == null){ + throw EeLogger.ROOT_LOGGER.defaultConstructorNotFound(mBeanClassHierarchy.get(0).getIndexedClass()); + } final Object mBeanInstance = ReflectionUtils.newInstance(constructor, params); {code} to throw DeploymentUnitProcessingException instead of NPE. When I undeployed the reproducer, I also noticed another NPE as: {code:xml} 15:47:55,317 WARN [org.jboss.msc.inject] (ServerService Thread Pool -- 62) MSC000100: Unexpected failure to uninject public void org.jboss.as.quickstarts.mbeanhelloworld.mbean.PropertyManagerDynamicBean.setPropertyFile(java.lang.String) throws java.io.IOException: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.msc.inject.MethodInjector.uninject(MethodInjector.java:119) at org.jboss.msc.service.ServiceControllerImpl$StopContextImpl.complete(ServiceControllerImpl.java:2623) at org.jboss.as.service.CreateDestroyService$2.run(CreateDestroyService.java:104) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.NullPointerException at java.io.File.(File.java:360) at org.jboss.as.quickstarts.mbeanhelloworld.mbean.PropertyManagerDynamicBean.getPropFile(PropertyManagerDynamicBean.java:151) at org.jboss.as.quickstarts.mbeanhelloworld.mbean.PropertyManagerDynamicBean.load(PropertyManagerDynamicBean.java:155) at org.jboss.as.quickstarts.mbeanhelloworld.mbean.PropertyManagerDynamicBean.setPropertyFile(PropertyManagerDynamicBean.java:176) ... 13 more {code} The 2nd one above is explained at https://issues.jboss.org/browse/WFLY-670?focusedCommentId=13028625&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13028625 > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 05:03:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Tue, 28 Mar 2017 05:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8457) TimerService.getTimers() does not return persisted timers in @PreDestroy method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated WFLY-8457: ----------------------------- Original Estimate: (was: 2 days) Remaining Estimate: (was: 2 days) > TimerService.getTimers() does not return persisted timers in @PreDestroy method > ------------------------------------------------------------------------------- > > Key: WFLY-8457 > URL: https://issues.jboss.org/browse/WFLY-8457 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Alpha1 > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Attachments: TimerBean.java, TimerServiceEJBBug.jar > > > Injecting the TimerService with an @Resource annotation > {quote} > @Resource > private TimerService timerService; > {quote} > When I call timerService.getTimers().size() in the @PreDestroy method, it always return 0. > If I deploy the same application in jboss eap 6, then timerService.getTimers().size() return 1. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 05:15:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Tue, 28 Mar 2017 05:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2402: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Required attributes of elytron key-store creation add operation > --------------------------------------------------------------- > > Key: WFCORE-2402 > URL: https://issues.jboss.org/browse/WFCORE-2402 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: user_experience > Fix For: 4.0.0.Alpha1 > > > Minimal CLI command to create key store is > {code} > /subsystem=elytron/key-store=server:add(type="JKS") > {code} > But it has these problems: > * Password attribute has to be required. I can't think of case when that could be ommited. > * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 05:15:00 2017 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Tue, 28 Mar 2017 05:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1038) Elytron Client with Management CLI still prompts for password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski moved WFCORE-2529 to ELY-1038: ------------------------------------------------- Project: WildFly Elytron (was: WildFly Core) Key: ELY-1038 (was: WFCORE-2529) Component/s: Authentication Client (was: Security) > Elytron Client with Management CLI still prompts for password > ------------------------------------------------------------- > > Key: ELY-1038 > URL: https://issues.jboss.org/browse/ELY-1038 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 05:41:00 2017 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Tue, 28 Mar 2017 05:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri resolved JBJCA-1341. ------------------------------------ Resolution: Done > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 06:31:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 28 Mar 2017 06:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2587) Confusing exception during deployment when ldap-realm does not include password reference In-Reply-To: References: Message-ID: Ondrej Lukas created WFCORE-2587: ------------------------------------ Summary: Confusing exception during deployment when ldap-realm does not include password reference Key: WFCORE-2587 URL: https://issues.jboss.org/browse/WFCORE-2587 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse In case when {{ldap-realm}} is configured with {{direct-verification=false}} and no {{identity-mapping.user-password-mapper}} is provided then deployment which using this realm fails with Exception: {code} ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:241) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) ... 6 more Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$6(ApplicationSecurityDomainDefinition.java:492) at java.lang.Iterable.forEach(Iterable.java:75) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:489) at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425) at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415) at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211) at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) ... 8 more {code} Throwing exception is correct since deployment has no possibility how to verify a password through given ldap-realm. However message given to user is confusing, it says "The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.". Information that ldap-realm is insufficiently configured for given deployment should be propagated to the user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 06:31:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 28 Mar 2017 06:31:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2587) Confusing exception during deployment when ldap-realm does not include password reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2587: --------------------------------- Labels: user_experience (was: ) > Confusing exception during deployment when ldap-realm does not include password reference > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2587 > URL: https://issues.jboss.org/browse/WFCORE-2587 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when {{ldap-realm}} is configured with {{direct-verification=false}} and no {{identity-mapping.user-password-mapper}} is provided then deployment which using this realm fails with Exception: > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:241) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > ... 6 more > Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$6(ApplicationSecurityDomainDefinition.java:492) > at java.lang.Iterable.forEach(Iterable.java:75) > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:489) > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425) > at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415) > at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > ... 8 more > {code} > Throwing exception is correct since deployment has no possibility how to verify a password through given ldap-realm. However message given to user is confusing, it says "The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.". Information that ldap-realm is insufficiently configured for given deployment should be propagated to the user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 06:32:00 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Tue, 28 Mar 2017 06:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2587) Confusing exception during deployment when ldap-realm does not include password reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas updated WFCORE-2587: --------------------------------- Affects Version/s: 3.0.0.Beta10 > Confusing exception during deployment when ldap-realm does not include password reference > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2587 > URL: https://issues.jboss.org/browse/WFCORE-2587 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta10 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when {{ldap-realm}} is configured with {{direct-verification=false}} and no {{identity-mapping.user-password-mapper}} is provided then deployment which using this realm fails with Exception: > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:241) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > ... 6 more > Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory. > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$6(ApplicationSecurityDomainDefinition.java:492) > at java.lang.Iterable.forEach(Iterable.java:75) > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:489) > at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425) > at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415) > at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239) > ... 8 more > {code} > Throwing exception is correct since deployment has no possibility how to verify a password through given ldap-realm. However message given to user is confusing, it says "The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.". Information that ldap-realm is insufficiently configured for given deployment should be propagated to the user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:02:01 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 28 Mar 2017 08:02:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFLY-8458: ----------------------------- Fix Version/s: (was: 11.0.0.Beta1) > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 11.0.0.Beta1 > > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:02:01 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 28 Mar 2017 08:02:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFLY-8458: ----------------------------- Fix Version/s: 11.0.0.Beta1 > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 11.0.0.Beta1 > > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:33:32 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Tue, 28 Mar 2017 08:33:32 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6473) BeanFactoryTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky reopened WFLY-6473: --------------------------------- Reopening due to state of the downstream issue. > BeanFactoryTestCase fails with security manager > ----------------------------------------------- > > Key: WFLY-6473 > URL: https://issues.jboss.org/browse/WFLY-6473 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > Fix For: 10.1.0.CR1, 10.1.0.Final > > > *org.jboss.as.test.integration.pojo.test.BeanFactoryTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.pojo.test.BeanFactoryTestCase -Dsecurity.manager}} > Fails with: > {code} > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/bean-factory.jar )" of "null") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at org.jboss.modules.Module.getClassLoader(Module.java:421) > at org.jboss.as.pojo.descriptor.BaseBeanFactory.create(BaseBeanFactory.java:44) > ... 19 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-817) Extremely poor performance of the topological sorting implementation for type declarations performs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-817: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Extremely poor performance of the topological sorting implementation for type declarations performs > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-817 > URL: https://issues.jboss.org/browse/DROOLS-817 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.Beta1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 7.0.0.CR1 > > > The current implementation suffers from thrashing. > In case of large business object models (e.g. derived from an ontology), > the analysis at package build time may take orders of magnitude more > than necessary -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1419) Make interface AccumulateFunction to avoid downcasting verbosity in implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-1419: ------------------------------------------- Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Make interface AccumulateFunction to avoid downcasting verbosity in implementations > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1419 > URL: https://issues.jboss.org/browse/DROOLS-1419 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > Priority: Minor > Fix For: 7.0.0.CR1 > > > Fix will NOT break backwards compatibility. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-744) Rule Generation Feature Request In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-744: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Rule Generation Feature Request > ------------------------------- > > Key: DROOLS-744 > URL: https://issues.jboss.org/browse/DROOLS-744 > Project: Drools > Issue Type: Feature Request > Components: core engine, kie server > Affects Versions: 6.2.0.Final > Reporter: Justin Holmes > Assignee: Mario Fusco > Fix For: 7.0.0.CR1 > > > As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems. > The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-680) "contains" operator behaves inconsistently when used with Maps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-680: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > "contains" operator behaves inconsistently when used with Maps > -------------------------------------------------------------- > > Key: DROOLS-680 > URL: https://issues.jboss.org/browse/DROOLS-680 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 7.0.0.CR1 > > > In a rule > {code} > Bean( map contains "x" ) // assuming "map" is a property of type Map > {code} > "contains" is arbitrarily interpreted as "containsKey" > The constrain will then fail after being jitted > The documentation explicitly states that "contains" applies to collections -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-670) Generalize inline casts to work with traits In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-670: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Generalize inline casts to work with traits > ------------------------------------------- > > Key: DROOLS-670 > URL: https://issues.jboss.org/browse/DROOLS-670 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.CR1 > > > The following constraint > {code} > Person( this#Worker( wage > 1000 ) ) > {code} > is admissible when Worker is a subtype of Person. > It should also be possible to use "#" when Worker is a donned trait. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-607) Match.getObjects() should reflect the patterns' order In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-607: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Match.getObjects() should reflect the patterns' order > ----------------------------------------------------- > > Key: DROOLS-607 > URL: https://issues.jboss.org/browse/DROOLS-607 > Project: Drools > Issue Type: Enhancement > Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final > Reporter: Davide Sottara > Assignee: Mark Proctor > Priority: Minor > Fix For: 7.0.0.CR1 > > > if Match.getObjects() is called on a rule with LHS A() B() C(), > the resulting list will have the matching objects in reversed order > - that is, [c, b, a] - making it more difficult to analyze it. > The object's position in the list should reflect the LHS. > The order should be preserved even when subnetworks are present. > For example, A() not B() C() should then result in the list [a, *, c ] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-542) Expose more Commands through the KieCommands API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-542: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Expose more Commands through the KieCommands API > ------------------------------------------------ > > Key: DROOLS-542 > URL: https://issues.jboss.org/browse/DROOLS-542 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.1.0.CR1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.CR1 > > > Not all Commands are exposed by the KieCommands API interface -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-470) Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-470: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) > --------------------------------------------------------------------------------------------------- > > Key: DROOLS-470 > URL: https://issues.jboss.org/browse/DROOLS-470 > Project: Drools > Issue Type: Enhancement > Components: decision tables > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Anstis > Labels: optaplanner-request-for-drools > Fix For: 7.0.0.CR1 > > > This DT should work: > ||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))|| > |guestName == "$param"|guestName == "$param"|doSomething();| > It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed. > Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule: > ||CONDITION||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation()||| > |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();| > Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:01 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-669: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Create "behavesAs" operator to support traiting > ----------------------------------------------- > > Key: DROOLS-669 > URL: https://issues.jboss.org/browse/DROOLS-669 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.CR1 > > > Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:36:02 2017 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Tue, 28 Mar 2017 08:36:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals configurable via kmodule.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-453: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta8) > Allow KieSession globals configurable via kmodule.xml > ----------------------------------------------------- > > Key: DROOLS-453 > URL: https://issues.jboss.org/browse/DROOLS-453 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.0.0.Final > Reporter: Anton Giertli > Assignee: Mark Proctor > Fix For: 7.0.0.CR1 > > > Looking at the current xsd of kmodule.xml > https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd > It is not possible to configure KieSession globals variables via kmodule.xml. > Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 08:50:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 28 Mar 2017 08:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source attribute should not be an attribute of all JGroups protocols In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro closed WFLY-7361. ------------------------------ Resolution: Done This was completed as part of https://issues.jboss.org/browse/WFLY-7882 > data-source attribute should not be an attribute of all JGroups protocols > ------------------------------------------------------------------------- > > Key: WFLY-7361 > URL: https://issues.jboss.org/browse/WFLY-7361 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference. > This can be registered separately from the generic protocol resource definition. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:03:00 2017 From: issues at jboss.org (Richard Opalka (JIRA)) Date: Tue, 28 Mar 2017 09:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2588) Deprecate optional dependencies in manifests and descriptors In-Reply-To: References: Message-ID: Richard Opalka created WFCORE-2588: -------------------------------------- Summary: Deprecate optional dependencies in manifests and descriptors Key: WFCORE-2588 URL: https://issues.jboss.org/browse/WFCORE-2588 Project: WildFly Core Issue Type: Enhancement Affects Versions: 3.0.0.Beta11 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:07:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Tue, 28 Mar 2017 09:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1500) DecisionTable single output typeRef inference In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1500: -------------------------------------- Summary: DecisionTable single output typeRef inference Key: DROOLS-1500 URL: https://issues.jboss.org/browse/DROOLS-1500 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari As for the example below, the low priority value is Referred, so the correct answer should be Declined: {code:xml} feel:string "High","Low","Medium" feel:string "Approved","Declined","Referred" isAffordable RiskCategory true "Low" "Approved" - "Medium" "Referred" true "High" "Declined" false - "Declined" {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:22:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-437) Add config option to fail deployment if private API is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-437: ---------------------------------- Assignee: (was: Tomaz Cerar) > Add config option to fail deployment if private API is used > ----------------------------------------------------------- > > Key: WFCORE-437 > URL: https://issues.jboss.org/browse/WFCORE-437 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Pete Muir > > This would allow users to have continuous integration jobs check if their app uses a private API by mistake, and have the job fail if it does. > Needed to automate the check that quickstarts only use public API. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:27:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3195) VFS root creation is wrong on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-3195: --------------------------------- Assignee: (was: Tomaz Cerar) > VFS root creation is wrong on Windows > ------------------------------------- > > Key: WFLY-3195 > URL: https://issues.jboss.org/browse/WFLY-3195 > Project: WildFly > Issue Type: Bug > Components: VFS > Reporter: David Lloyd > > This may ultimately be a problem with VFS, or with WildFly. > We create our deployment root with an absolute VFS path of {{/content}} (see https://github.com/wildfly/wildfly/blob/dca817f584a24525c5a2f2f655aefed6d69466cf/server/src/main/java/org/jboss/as/server/deployment/module/DeploymentRootMountProcessor.java#L79 for details). However on Windows, we have special path handling (see https://github.com/jbossas/jboss-vfs/blob/eff9d8ae6d49e30038126304b5858c6c0937d672/src/main/java/org/jboss/vfs/VFS.java#L180 for details) which causes these paths to become absolute with a drive letter (e.g. {{W:/tmp/blah/foo/content/...}}) but only on windows. This makes writing policy files (for EAP) quite difficult, as well as just being generally wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:27:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBVFS-191) Support getCodeSigners() on RealFileSystem (and RootFileSystem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBVFS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned JBVFS-191: --------------------------------- Assignee: (was: Tomaz Cerar) > Support getCodeSigners() on RealFileSystem (and RootFileSystem) > --------------------------------------------------------------- > > Key: JBVFS-191 > URL: https://issues.jboss.org/browse/JBVFS-191 > Project: JBoss VFS > Issue Type: Feature Request > Affects Versions: 3.2.0.Beta1 > Reporter: David Lloyd > Fix For: 3.2.0.Beta2 > > > The {{getCodeSigners()}} method is a no-op on non-JAR filesystems, which causes security issues when a security manager is enabled. Simulate the behavior of JarFile for this method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:30:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 28 Mar 2017 09:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-10) [QE] - JMAN4-154 - Install the in-process agent via RPM into an RPM installed EAP 6 installation. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-10: ----------------------------------- Reference: https://docs.engineering.redhat.com/display/JP/CloudForms+Middleware+-+EAP+6+RPM+Agent+Install > [QE] - JMAN4-154 - Install the in-process agent via RPM into an RPM installed EAP 6 installation. > ------------------------------------------------------------------------------------------------- > > Key: HAWKULARQE-10 > URL: https://issues.jboss.org/browse/HAWKULARQE-10 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Sunil kondkar > Labels: mm-integration-hawkular-qe > > See [JMAN4-154|https://issues.jboss.org/browse/JMAN4-154] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:34:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 28 Mar 2017 09:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-12) [QE] - JMAN4-174 - Distribute the EAP agent in the EAP 6 RPM channel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-12: ----------------------------------- Ref: https://docs.engineering.redhat.com/display/JP/CloudForms+Middleware+-+EAP+6+RPM+Agent+Install > [QE] - JMAN4-174 - Distribute the EAP agent in the EAP 6 RPM channel > -------------------------------------------------------------------- > > Key: HAWKULARQE-12 > URL: https://issues.jboss.org/browse/HAWKULARQE-12 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Sunil kondkar > Labels: mm-integration-hawkular-qe > > See [JMAN4-174|https://issues.jboss.org/browse/JMAN4-174] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:34:00 2017 From: issues at jboss.org (Richard Opalka (JIRA)) Date: Tue, 28 Mar 2017 09:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage In-Reply-To: References: Message-ID: Richard Opalka created WFCORE-2589: -------------------------------------- Summary: Eliminate MSC OPTIONAL dependencies usage Key: WFCORE-2589 URL: https://issues.jboss.org/browse/WFCORE-2589 Project: WildFly Core Issue Type: Task Affects Versions: 3.0.0.Beta11 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:35:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 28 Mar 2017 09:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-9) [QE] - JMAN4-152 - Install the in-process agent via RPM into an RPM installed EAP 7 installation. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-9: ---------------------------------- Ref: https://docs.engineering.redhat.com/display/JP/CloudForms+Middleware+-+EAP+7+RPM+Agent+Install > [QE] - JMAN4-152 - Install the in-process agent via RPM into an RPM installed EAP 7 installation. > ------------------------------------------------------------------------------------------------- > > Key: HAWKULARQE-9 > URL: https://issues.jboss.org/browse/HAWKULARQE-9 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Filip Brychta > Labels: mm-integration-hawkular-qe > > See [JMAN4-152|https://issues.jboss.org/browse/JMAN4-152] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:35:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 28 Mar 2017 09:35:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-13) [QE] - JMAN4-175 - Distribute the EAP agent in the EAP 7 RPM channels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-13: ----------------------------------- Ref: https://docs.engineering.redhat.com/display/JP/CloudForms+Middleware+-+EAP+7+RPM+Agent+Install > [QE] - JMAN4-175 - Distribute the EAP agent in the EAP 7 RPM channels > --------------------------------------------------------------------- > > Key: HAWKULARQE-13 > URL: https://issues.jboss.org/browse/HAWKULARQE-13 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Filip Brychta > Labels: mm-integration-hawkular-qe > > See [JMAN4-175|https://issues.jboss.org/browse/JMAN4-175] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:36:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1263) Beef up testsuite coverage of web deployment metrics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-1263. ----------------------------- Resolution: Deferred > Beef up testsuite coverage of web deployment metrics > ---------------------------------------------------- > > Key: WFLY-1263 > URL: https://issues.jboss.org/browse/WFLY-1263 > Project: WildFly > Issue Type: Task > Components: Domain Management, Web (Undertow) > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > > More tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:36:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2513) Wildfly 10.1.0.Final does not start as a linux service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFCORE-2513. ------------------------------- Resolution: Cannot Reproduce Bug > Wildfly 10.1.0.Final does not start as a linux service > ------------------------------------------------------ > > Key: WFCORE-2513 > URL: https://issues.jboss.org/browse/WFCORE-2513 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: Oracle Linux Server release 6.7, Oracle, Java 8 > Reporter: mohammed hilout > Assignee: Tomaz Cerar > > I follow this article to run WildFly as service: "http://developer-should-know.com/post/112230363742/how-to-install-wildfly-as-a-service-on-linux" > I can start / stop service, but wildfly don't run on boot -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:37:00 2017 From: issues at jboss.org (Richard Opalka (JIRA)) Date: Tue, 28 Mar 2017 09:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2590) Deprecate org.jboss.as.server.Services.addServerExecutorDependency() with DependencyType parameter In-Reply-To: References: Message-ID: Richard Opalka created WFCORE-2590: -------------------------------------- Summary: Deprecate org.jboss.as.server.Services.addServerExecutorDependency() with DependencyType parameter Key: WFCORE-2590 URL: https://issues.jboss.org/browse/WFCORE-2590 Project: WildFly Core Issue Type: Sub-task Affects Versions: 3.0.0.Beta11 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:40:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6952) Provide way to display deployed application metadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-6952: --------------------------------- Assignee: Stuart Douglas (was: Tomaz Cerar) > Provide way to display deployed application metadata > ---------------------------------------------------- > > Key: WFLY-6952 > URL: https://issues.jboss.org/browse/WFLY-6952 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Nicklas Karlsson > Assignee: Stuart Douglas > > It would be handy to have the deployment process print out the complete DeploymentInfo for an application so one could view the final order of filters and request listeners etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:40:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:40:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6952) Provide way to display deployed application metadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-6952: --------------------------------- Assignee: (was: Stuart Douglas) > Provide way to display deployed application metadata > ---------------------------------------------------- > > Key: WFLY-6952 > URL: https://issues.jboss.org/browse/WFLY-6952 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Nicklas Karlsson > > It would be handy to have the deployment process print out the complete DeploymentInfo for an application so one could view the final order of filters and request listeners etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:41:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-1530: -------------------------------- Component/s: IO > It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1530 > URL: https://issues.jboss.org/browse/WFCORE-1530 > Project: WildFly Core > Issue Type: Enhancement > Components: IO > Affects Versions: 2.1.0.Final > Reporter: Juan AMAT > Assignee: Tomaz Cerar > > We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly. > While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly. > Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count. > We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers). > It will be nicer to be able to configure instead a per-cpu value. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:41:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-1530: ----------------------------------- Assignee: (was: Tomaz Cerar) > It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1530 > URL: https://issues.jboss.org/browse/WFCORE-1530 > Project: WildFly Core > Issue Type: Enhancement > Components: IO > Affects Versions: 2.1.0.Final > Reporter: Juan AMAT > > We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly. > While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly. > Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count. > We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers). > It will be nicer to be able to configure instead a per-cpu value. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:41:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:41:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBVFS-198) Correct or remove usage of finalize in VFS, TempDir, and TempFileProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBVFS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned JBVFS-198: --------------------------------- Assignee: (was: Tomaz Cerar) > Correct or remove usage of finalize in VFS, TempDir, and TempFileProvider > ------------------------------------------------------------------------- > > Key: JBVFS-198 > URL: https://issues.jboss.org/browse/JBVFS-198 > Project: JBoss VFS > Issue Type: Task > Reporter: Jason Greene > Fix For: 3.2.13.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:42:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-602) Ability to view an objects index of it's position in a list. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-602: ---------------------------------- Assignee: (was: Tomaz Cerar) > Ability to view an objects index of it's position in a list. > ------------------------------------------------------------ > > Key: WFCORE-602 > URL: https://issues.jboss.org/browse/WFCORE-602 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Labels: affects_elytron > > General improvements are being made to the management model for more fine grained manipulation of complex attributes, amongst these changes will be the ability to insert items at a specific position in a list. > This feature request is to ask for the ability to see an items index to identify it's position. > i.e. an end user can call :read-recource and see an items position without needing to count how many items there are in order to identify the position of the next insert. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:52:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1451) Unify/add unwrap methods to most of AttributeDefinition classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-1451: -------------------------------- Component/s: Domain Management > Unify/add unwrap methods to most of AttributeDefinition classes > --------------------------------------------------------------- > > Key: WFCORE-1451 > URL: https://issues.jboss.org/browse/WFCORE-1451 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > we now have unwrap method only on StringListAD and PropertiesAD. but there are handful of others that should have it to if possible. > Thing to keep in mind is to make sure collection attributes can also return null as introduced in WFCORE-1448 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 09:53:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 09:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1451) Unify/add unwrap methods to most of AttributeDefinition classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-1451: ----------------------------------- Assignee: (was: Tomaz Cerar) > Unify/add unwrap methods to most of AttributeDefinition classes > --------------------------------------------------------------- > > Key: WFCORE-1451 > URL: https://issues.jboss.org/browse/WFCORE-1451 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Tomaz Cerar > > we now have unwrap method only on StringListAD and PropertiesAD. but there are handful of others that should have it to if possible. > Thing to keep in mind is to make sure collection attributes can also return null as introduced in WFCORE-1448 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:04:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 10:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2386: ------------------------------------- Fix Version/s: 3.0.0.Alpha24 (was: 3.0.0.Beta12) > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Alpha24 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > Error401 - Unauthorized > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > Error401 - Unauthorized > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:04:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 10:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-2386. -------------------------------------- Resolution: Done > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Alpha24 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > Error401 - Unauthorized > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > Error401 - Unauthorized > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:13:00 2017 From: issues at jboss.org (Matt Mahoney (JIRA)) Date: Tue, 28 Mar 2017 10:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-33) [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Mahoney updated HAWKULARQE-33: ----------------------------------- Ref: https://github.com/ManageIQ/manageiq-ui-classic/pull/460 This feature is currently available in upstream MIQ:latest > [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider > ------------------------------------------------------------- > > Key: HAWKULARQE-33 > URL: https://issues.jboss.org/browse/HAWKULARQE-33 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Vojtech Prusa > Priority: Critical > Labels: mm-integration-hawkular-qe > > See [JMAN4-188|https://issues.jboss.org/browse/JMAN4-188] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:22:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 10:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1515) Improve PersistentResourceDefinition to make it easier to register attribute write handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-1515: ----------------------------------- Assignee: (was: Tomaz Cerar) > Improve PersistentResourceDefinition to make it easier to register attribute write handlers > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1515 > URL: https://issues.jboss.org/browse/WFCORE-1515 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > > Currently if you want to take register custom write handler you need to override whole registerAttributes methods and do it yourself all the way. > We could add PersistentResourceDefinition.getAttributeHandlers() method that returns > a Map. > And then registerAttributes uses the map instead of hardcoding ReloadRequiredWriteAttributeHandler. Default impl just fills the map values with > ReloadRequiredWriteAttributeHandler. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:24:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 10:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2398) Legacy Kerberos in management, EAP search for HTTPS/localhost ticket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2398: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Legacy Kerberos in management, EAP search for HTTPS/localhost ticket > -------------------------------------------------------------------- > > Key: WFCORE-2398 > URL: https://issues.jboss.org/browse/WFCORE-2398 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta12 > > > Accessing management interface secured by Kerberos + TLS causes EAP requests from KDC ticket HTTPS/localhost. Which was not necessary in EAP 7.0 and it worked fine with HTTP/localhost service name > {code:title=server.log} > 14:20:19,321 TRACE [org.jboss.as.domain.management.security] (management task-7) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match. > 14:20:19,322 TRACE [org.jboss.as.domain.management.security] (management task-7) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 14:20:19,322 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,524 WARN [org.apache.directory.server.protocol.shared.kerberos.StoreUtils] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain at JBOSS.ORG > 14:20:19,524 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain at JBOSS.ORG > 14:20:19,524 WARN [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler] (NioDatagramAcceptor-3) Server not found in Kerberos database (7) > 14:20:19,525 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) Server not found in Kerberos database (7) > 14:20:19,528 WARN [org.apache.http.impl.auth.HttpAuthenticator] (main) NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - Server not found in Kerberos database)) > 14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match. > 14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain at JBOSS.ORG > [Krb5LoginModule]: Entering logout > [Krb5LoginModule]: logged out Subject > {code} > Also see network dump krb_https_management.pcap in attachement, where TGS-REQ for HTTPS/localhost is captured. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:31:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Tue, 28 Mar 2017 10:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2535) ModuleResourceRootPathsTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet reassigned WFCORE-2535: ----------------------------------------- Assignee: ehsavoie Hugonnet > ModuleResourceRootPathsTestCase fails with security manager in WF core > ---------------------------------------------------------------------- > > Key: WFCORE-2535 > URL: https://issues.jboss.org/browse/WFCORE-2535 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.jboss.as.test.integration.management.cli.modules.ModuleResourceRootPathsTestCase#testModules* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=ModuleResourceRootPathsTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:26:00,583 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."test-archive.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-archive.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "test-archive.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "jboss.bind.address" "read")" in code source "(vfs:/content/test-archive.war )" of "ModuleClassLoader for Module "deployment.test-archive.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) > at java.lang.System.getProperty(System.java:443) > at java.lang.System.getProperty(System.java:427) > at org.jboss.as.test.shared.TestSuiteEnvironment.getSystemProperty(TestSuiteEnvironment.java:50) > at org.jboss.as.test.shared.TestSuiteEnvironment.getHttpAddress(TestSuiteEnvironment.java:173) > at org.wildfly.test.undertow.UndertowServiceActivator.getAddress(UndertowServiceActivator.java:100) > at org.wildfly.test.undertow.UndertowServiceActivator.activate(UndertowServiceActivator.java:66) > at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:37:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Tue, 28 Mar 2017 10:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-40) XA Datasource creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385262#comment-13385262 ] Hayk Hovsepyan commented on HAWKULARQE-40: ------------------------------------------ Manual Testcase is created and run https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-9540 https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%2058%2DDR3 No issue was found. > XA Datasource creation > ---------------------- > > Key: HAWKULARQE-40 > URL: https://issues.jboss.org/browse/HAWKULARQE-40 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Manual testcases. > Automation testcases. > BZ should be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1383611 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:43:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Tue, 28 Mar 2017 10:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2591) deployment add/add-content alternatives and required issues In-Reply-To: References: Message-ID: Jean-Francois Denise created WFCORE-2591: -------------------------------------------- Summary: deployment add/add-content alternatives and required issues Key: WFCORE-2591 URL: https://issues.jboss.org/browse/WFCORE-2591 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Jean-Francois Denise Assignee: Brian Stansberry Priority: Minor add operation - content should be required. - alternatives hash/bytes/url/path/input-stream-index should be required. add-content operation - content should be required. - alternatives input-stream-index/hash/bytes/url should be required. - alternatives empty/relative-to/path should not be present in alternatives list. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:48:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Tue, 28 Mar 2017 10:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2591) deployment add/add-content alternatives and required issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise updated WFCORE-2591: ----------------------------------------- Description: add operation - content should be required. - alternatives hash/bytes/url/path/input-stream-index/empty should be required. add-content operation - content should be required. - alternatives input-stream-index/hash/bytes/url should be required. - alternatives empty/relative-to/path should not be present in alternatives list. was: add operation - content should be required. - alternatives hash/bytes/url/path/input-stream-index should be required. add-content operation - content should be required. - alternatives input-stream-index/hash/bytes/url should be required. - alternatives empty/relative-to/path should not be present in alternatives list. > deployment add/add-content alternatives and required issues > ----------------------------------------------------------- > > Key: WFCORE-2591 > URL: https://issues.jboss.org/browse/WFCORE-2591 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > Priority: Minor > > add operation > - content should be required. > - alternatives hash/bytes/url/path/input-stream-index/empty should be required. > add-content operation > - content should be required. > - alternatives input-stream-index/hash/bytes/url should be required. > - alternatives empty/relative-to/path should not be present in alternatives list. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 10:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 28 Mar 2017 10:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reopened WFLY-8458: ------------------------------------ Hi [~soul2zimate] -- please update this fix to not use EeLogger. Logger interfaces should not be used outside their own module. Thanks! > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 11.0.0.Beta1 > > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:07:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 11:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-89) Sub ResourceDefinitions shouldn't need ResourceDescriptionResolver In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-89: --------------------------------- Assignee: (was: Tomaz Cerar) > Sub ResourceDefinitions shouldn't need ResourceDescriptionResolver > ------------------------------------------------------------------ > > Key: WFCORE-89 > URL: https://issues.jboss.org/browse/WFCORE-89 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > > We could omit forcing users to have resolver set for all subresources as in most cases it is the same and predictable. > We could just reuse parent's resolver with some extra prefix. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:09:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 28 Mar 2017 11:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2592) wildfly-service.exe and jbosspass wrong with # inside In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved WFLY-7715 to WFCORE-2592: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2592 (was: WFLY-7715) Component/s: Scripts (was: Scripts) > wildfly-service.exe and jbosspass wrong with # inside > ----------------------------------------------------- > > Key: WFCORE-2592 > URL: https://issues.jboss.org/browse/WFCORE-2592 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Seb Dk > Assignee: Tomaz Cerar > > Hi there, > > I am installing wildfy 10.1.0 as service on a win 20012 server. > It is working but I cannot stop the service. > I figured out where the problem is coming from. > > When I installe Wildly as a service, I run the following command: > E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass *my#pass* > > But I can see whe I am trying to stop the service, the command running is: > E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=*my" "pass* --command=:shutdown > > Any workaround? > > Thanks, > > S. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:12:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 28 Mar 2017 11:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-150) Add support for a more generic error handler In-Reply-To: References: Message-ID: James Perkins created LOGMGR-150: ------------------------------------ Summary: Add support for a more generic error handler Key: LOGMGR-150 URL: https://issues.jboss.org/browse/LOGMGR-150 Project: JBoss Log Manager Issue Type: Enhancement Reporter: James Perkins There are places, such as in the {{org.jboss.logmanager.LoggerNode}}, where exceptions are swallowed. Handlers have use an {{java.util.logging.ErrorHandler}}, but formatters and loggers do not. It would be helpful to have a way to either reuse or create a similar error handler concept for loggers and formatters. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:18:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 28 Mar 2017 11:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1501) CCE modifying a polymorphic object over a window In-Reply-To: References: Message-ID: Mario Fusco created DROOLS-1501: ----------------------------------- Summary: CCE modifying a polymorphic object over a window Key: DROOLS-1501 URL: https://issues.jboss.org/browse/DROOLS-1501 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco Modifying an object matched in a polymorphic way and using a window like in this test case: {code} @Test public void testModifySubclassOverWindow() { // DROOLS- String drl = "declare Number @role( event ) end\n" + "declare Integer @role( event ) end\n" + "\n" + "rule R1 no-loop when\n" + " $i: Integer()\n" + "then\n" + " update($i);\n" + "end\n" + "rule R2 when\n" + " $n: Number() over window:length(1)\n" + "then\n" + "end"; KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL ) .build( EventProcessingOption.STREAM ) .newKieSession(); ksession.insert(1); ksession.fireAllRules(); } {code} causes a CCE like the following: {code} java.lang.ClassCastException: org.drools.core.reteoo.WindowNode cannot be cast to org.drools.core.reteoo.BetaNode at org.drools.core.reteoo.EntryPointNode.removeRightTuplesMatchingOTN(EntryPointNode.java:263) at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:253) at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:245) at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:217) at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:93) at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:83) at org.drools.core.common.DefaultAgenda.flushPropagations(DefaultAgenda.java:1275) at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:143) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:89) at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:37) at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1074) at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1021) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1013) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1315) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1306) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1290) at org.drools.compiler.integrationtests.PolymorphismTest.testModifySubclassOverWindow(PolymorphismTest.java:50) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:21:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 28 Mar 2017 11:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1501) CCE modifying a polymorphic object over a window In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385292#comment-13385292 ] Mario Fusco commented on DROOLS-1501: ------------------------------------- Reproduced here https://github.com/kiegroup/drools/pull/1175 > CCE modifying a polymorphic object over a window > ------------------------------------------------ > > Key: DROOLS-1501 > URL: https://issues.jboss.org/browse/DROOLS-1501 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > > Modifying an object matched in a polymorphic way and using a window like in this test case: > {code} > @Test > public void testModifySubclassOverWindow() { > // DROOLS- > String drl = "declare Number @role( event ) end\n" + > "declare Integer @role( event ) end\n" + > "\n" + > "rule R1 no-loop when\n" + > " $i: Integer()\n" + > "then\n" + > " update($i);\n" + > "end\n" + > "rule R2 when\n" + > " $n: Number() over window:length(1)\n" + > "then\n" + > "end"; > KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL ) > .build( EventProcessingOption.STREAM ) > .newKieSession(); > ksession.insert(1); > ksession.fireAllRules(); > } > {code} > causes a CCE like the following: > {code} > java.lang.ClassCastException: org.drools.core.reteoo.WindowNode cannot be cast to org.drools.core.reteoo.BetaNode > at org.drools.core.reteoo.EntryPointNode.removeRightTuplesMatchingOTN(EntryPointNode.java:263) > at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:253) > at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:245) > at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:217) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:93) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:83) > at org.drools.core.common.DefaultAgenda.flushPropagations(DefaultAgenda.java:1275) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:143) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:89) > at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:37) > at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1074) > at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1021) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1013) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1315) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1306) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1290) > at org.drools.compiler.integrationtests.PolymorphismTest.testModifySubclassOverWindow(PolymorphismTest.java:50) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:54:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 28 Mar 2017 11:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-2245. -------------------------------------- Fix Version/s: (was: 3.0.0.Beta12) Assignee: Brian Stansberry (was: Darran Lofthouse) Resolution: Duplicate Issue [~claudio4j] Please follow WFCORE-2433 > credential-reference capability-reference constraint > ---------------------------------------------------- > > Key: WFCORE-2245 > URL: https://issues.jboss.org/browse/WFCORE-2245 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Claudio Miranda > Assignee: Brian Stansberry > > There attribute credential-reference is defined in many subsystems as below. Looks like the capability-reference constraint should be set in the "store" field of the value-type, therefore I request a review on this capability-constraint placement. > {code} > "credential-reference" => { > "type" => OBJECT, > "description" => "Credential (from Credential Store) to authenticate on data source", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.credential-store", > "access-constraints" => {"sensitive" => { > "credential" => {"type" => "core"}, > "data-source-security" => {"type" => "datasources"} > }}, > "value-type" => { > "store" => { > "type" => STRING, > "description" => "The name of the credential store holding the alias to credential", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "alias" => { > "type" => STRING, > "description" => "The alias which denotes stored secret or credential in the store", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "type" => { > "type" => STRING, > "description" => "The type of credential this reference is denoting", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "clear-text" => { > "type" => STRING, > "description" => "Secret specified using clear text (check credential store way of supplying credential/secrets to services)", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:55:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 28 Mar 2017 11:55:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2433) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2433: ---------------------------------------- Assignee: Brian Stansberry (was: Peter Skopek) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2433 > URL: https://issues.jboss.org/browse/WFCORE-2433 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 11:58:00 2017 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Tue, 28 Mar 2017 11:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5419) Deployed webservices in war do not show up in admin console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Miranda closed WFLY-5419. --------------------------------- Assignee: Claudio Miranda (was: Heiko Braun) Resolution: Cannot Reproduce Hi, I couldn't reproduce. If you feel this is not right, you make sure to reproduce and reopen. > Deployed webservices in war do not show up in admin console > ----------------------------------------------------------- > > Key: WFLY-5419 > URL: https://issues.jboss.org/browse/WFLY-5419 > Project: WildFly > Issue Type: Bug > Components: Web Console, Web Services > Affects Versions: 9.0.1.Final, 10.0.0.CR2 > Reporter: skarimir skarimir > Assignee: Claudio Miranda > > Webservices deployed in a war do not show up in the Administration Console under runtime > subsystems > webservices. This works in wildfly 8 with the same war. You can reproduce this using the quickstart example https://github.com/wildfly/quickstart/tree/9.x/helloworld-ws -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 12:29:00 2017 From: issues at jboss.org (Pedro Igor (JIRA)) Date: Tue, 28 Mar 2017 12:29:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385406#comment-13385406 ] Pedro Igor commented on ELY-1030: --------------------------------- [~dlofthouse], I forgot about an important detail :) We do have other classes related with token realm and these are what we call "token validators". For now we have JWT and OAuth2 (token introspection) validators and in the future we may introduce even more if necessary. So, I think we should keep the package structure as it is. > Move TokenSecurityRealm to org.wildfly.security.auth.realm package > ------------------------------------------------------------------ > > Key: ELY-1030 > URL: https://issues.jboss.org/browse/ELY-1030 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta34 > > > The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 12:36:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Tue, 28 Mar 2017 12:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2484) CS tool, log exception on error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2484: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > CS tool, log exception on error > ------------------------------- > > Key: WFCORE-2484 > URL: https://issues.jboss.org/browse/WFCORE-2484 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > Labels: credential-store, wildfly-elytron-tool > > When I try to create CS with invalid options I get just {{ELY09526: Unable to initialize credential store}}. For example: > * I tried JKS, but JKS is unable to store secret keys > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JKS" --password mycspassword --salt 12345678 --iteration 230 --summary > ELY09526: Unable to initialize credential store[mchoma at localhost bin]$ > {code} > * I tried BKS, but have not BC among providers > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=BKS" --password mycspassword --salt 12345678 --iteration 230 --summary > ELY09526: Unable to initialize credential store > {code} > It would be useful if underlying exception is logged as well. For example subsystem throws this exception and it is obvious what is wrong. > {code} > Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09526: Unable to initialize credential store > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:834) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:758) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:163) > at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:119) > at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:117) > ... 5 more > Caused by: java.security.KeyStoreException: BKS not found > at java.security.KeyStore.getInstance(KeyStore.java:851) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:832) > ... 9 more > Caused by: java.security.NoSuchAlgorithmException: BKS KeyStore not available > at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) > at java.security.Security.getImpl(Security.java:695) > at java.security.KeyStore.getInstance(KeyStore.java:848) > ... 10 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 12:38:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 12:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2477) Legacy Kerberos in management, regression in choosing keytab strategy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2477: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Legacy Kerberos in management, regression in choosing keytab strategy > --------------------------------------------------------------------- > > Key: WFCORE-2477 > URL: https://issues.jboss.org/browse/WFCORE-2477 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > There is regresion in strategy of choosing keytab described by xsd > {code:xml|title=wildfly-config_5_0.xsd} > > > > > Reference to an individual keytab. > On handling the authentication for an incoming request two pieces of information are known, the protocol and the name of the host > this server is acting as. For HTTP requests the protocol will always be HTTP, for requests over Remoting by default the protocol will > be 'remote' although this can be overridden. > At the time authentication is going to be handled the keytab will be selected as follows: - > 1 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching protocol/hostname. > 2 - Iterate the list of keytabs and identify one where the name of the principal matches matches protocol/hostname. > 3 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching hostname. > 4 - Iterate the list of keytabs and identify one where the hostname portion of the principal matches the hostname of the request. > 5 - Use the keytab where for-hosts is set to '*'. > If no match is found no keytab will be selected and Kerberos will not be available for communication as that host. > > > {code} > In this example > {code:xml|title=standalone.xlm} > > > > > > > {code} > Rule 1 should be applied, but {{}} is chosen, > {code:title=server.log} > 10:28:40,743 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:28:40,744 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 10:28:40,744 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,847 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:28:40,848 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > {code} > In this example > {code:xml|title=standalone.xlm} > > > > > > > {code} > Rule 2 should be applied, but {{}} is chosen > {code:title=server.log} > 10:29:21,889 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:29:21,890 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/wronghost at JBOSS.ORG' for host 'localhost.localdomain' > 10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/wronghost at JBOSS.ORG' for host 'localhost.localdomain' > 10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,959 INFO [stdout] (management task-9) Entered Krb5Context.acceptSecContext with state=STATE_NEW > 10:29:21,960 INFO [stdout] (management task-9) Looking for keys for: HTTP/wronghost at JBOSS.ORG > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 12:40:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 12:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2477) Legacy Kerberos in management, regression in choosing keytab strategy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-2477. -------------------------------------- Resolution: Duplicate Issue This is the same issue as covered by WFCORE-2398 Effectively for both issues the protocol had become 'http' / 'https' when for http requests it should always be 'HTTP'. > Legacy Kerberos in management, regression in choosing keytab strategy > --------------------------------------------------------------------- > > Key: WFCORE-2477 > URL: https://issues.jboss.org/browse/WFCORE-2477 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > > There is regresion in strategy of choosing keytab described by xsd > {code:xml|title=wildfly-config_5_0.xsd} > > > > > Reference to an individual keytab. > On handling the authentication for an incoming request two pieces of information are known, the protocol and the name of the host > this server is acting as. For HTTP requests the protocol will always be HTTP, for requests over Remoting by default the protocol will > be 'remote' although this can be overridden. > At the time authentication is going to be handled the keytab will be selected as follows: - > 1 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching protocol/hostname. > 2 - Iterate the list of keytabs and identify one where the name of the principal matches matches protocol/hostname. > 3 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching hostname. > 4 - Iterate the list of keytabs and identify one where the hostname portion of the principal matches the hostname of the request. > 5 - Use the keytab where for-hosts is set to '*'. > If no match is found no keytab will be selected and Kerberos will not be available for communication as that host. > > > {code} > In this example > {code:xml|title=standalone.xlm} > > > > > > > {code} > Rule 1 should be applied, but {{}} is chosen, > {code:title=server.log} > 10:28:40,743 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:28:40,744 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 10:28:40,744 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,847 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:28:40,848 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain at JBOSS.ORG' for host 'localhost.localdomain' > 10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > 10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain at JBOSS.ORG > {code} > In this example > {code:xml|title=standalone.xlm} > > > > > > > {code} > Rule 2 should be applied, but {{}} is chosen > {code:title=server.log} > 10:29:21,889 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:29:21,890 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/wronghost at JBOSS.ORG' for host 'localhost.localdomain' > 10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/wronghost at JBOSS.ORG' for host 'localhost.localdomain' > 10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost at JBOSS.ORG > 10:29:21,959 INFO [stdout] (management task-9) Entered Krb5Context.acceptSecContext with state=STATE_NEW > 10:29:21,960 INFO [stdout] (management task-9) Looking for keys for: HTTP/wronghost at JBOSS.ORG > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 13:12:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 13:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2309) username-load attribute of legacy LDAP Realm stop to work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2309: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > username-load attribute of legacy LDAP Realm stop to work > --------------------------------------------------------- > > Key: WFCORE-2309 > URL: https://issues.jboss.org/browse/WFCORE-2309 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > {{username-load}} attribute of legacy LDAP Realm stop to work. This attribute is used for assigning username from some LDAP entry attribute. In current behavior it seems that it tries to search user in LDAP through value obtained from entry 'username-load' attribute. See JBEAP-8969 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 13:27:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 28 Mar 2017 13:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2309) username-load attribute of legacy LDAP Realm stop to work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385429#comment-13385429 ] Darran Lofthouse commented on WFCORE-2309: ------------------------------------------ I suspect it is this fix that has changed the behaviour https://issues.jboss.org/browse/WFCORE-2230 > username-load attribute of legacy LDAP Realm stop to work > --------------------------------------------------------- > > Key: WFCORE-2309 > URL: https://issues.jboss.org/browse/WFCORE-2309 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > {{username-load}} attribute of legacy LDAP Realm stop to work. This attribute is used for assigning username from some LDAP entry attribute. In current behavior it seems that it tries to search user in LDAP through value obtained from entry 'username-load' attribute. See JBEAP-8969 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 14:27:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Tue, 28 Mar 2017 14:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2593) DeploymentReflectionIndex requires additional permissions even if it is guarded by ServerPermission("createDeploymentReflectionIndex") In-Reply-To: References: Message-ID: Ivo Studensky created WFCORE-2593: ------------------------------------- Summary: DeploymentReflectionIndex requires additional permissions even if it is guarded by ServerPermission("createDeploymentReflectionIndex") Key: WFCORE-2593 URL: https://issues.jboss.org/browse/WFCORE-2593 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 3.0.0.Beta11 Reporter: Ivo Studensky Assignee: Ivo Studensky When running with Security Manager enabled, {{DeploymentReflectionIndex}} requires additional permissions (see below) even if its creation is guarded by {{ServerPermission("createDeploymentReflectionIndex")}}. Required additional permissions: {noformat} new RuntimePermission("accessDeclaredMembers") new ReflectPermission("suppressAccessChecks")) {noformat} It is actually the constructor of {{ClassReflectionIndex}} invoked from {{DeploymentReflectionIndex#getClassIndex()}} method which requires these permissions. This issue was catched by {{org.jboss.as.test.integration.pojo.test.BeanFactoryTestCase}}, see the stacktrace: {noformat} 20:24:38,511 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.pojo.D.CREATE: org.jboss.msc.service.StartException in service jboss.pojo.D.CREATE: java.lang.reflect.InvocationTargetException at org.jboss.as.pojo.service.LifecyclePojoPhase.startInternal(LifecyclePojoPhase.java:51) at org.jboss.as.pojo.service.AbstractPojoPhase.start(AbstractPojoPhase.java:75) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) 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.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.as.pojo.service.MethodJoinpoint.dispatch(MethodJoinpoint.java:41) at org.jboss.as.pojo.service.BeanUtils.dispatchLifecycleJoinpoint(BeanUtils.java:155) at org.jboss.as.pojo.service.LifecyclePojoPhase.dispatchJoinpoint(LifecyclePojoPhase.java:43) at org.jboss.as.pojo.service.LifecyclePojoPhase.startInternal(LifecyclePojoPhase.java:49) ... 6 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.as.test.integration.pojo.support.D.create(D.java:36) ... 14 more Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class org.jboss.as.test.integration.pojo.support.B with ClassLoader ModuleClassLoader for Module "deployment.bean-factory.jar" from Service Module Loader at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) at org.jboss.as.pojo.service.DefaultBeanInfo.lookup(DefaultBeanInfo.java:78) at org.jboss.as.pojo.service.DefaultBeanInfo.getConstructor(DefaultBeanInfo.java:86) at org.jboss.as.pojo.service.BeanUtils.instantiateBean(BeanUtils.java:98) at org.jboss.as.pojo.descriptor.BaseBeanFactory.create(BaseBeanFactory.java:62) ... 19 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/bean-factory.jar )" of "ModuleClassLoader for Module "deployment.bean-factory.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.Class.checkMemberAccess(Class.java:2348) at java.lang.Class.getDeclaredFields(Class.java:1915) at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.(ClassReflectionIndex.java:72) at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66) ... 23 more {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 15:07:00 2017 From: issues at jboss.org (Richard Opalka (JIRA)) Date: Tue, 28 Mar 2017 15:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Opalka updated WFCORE-2589: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2282 (was: https://github.com/wildfly/wildfly-core/pull/2281) > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Affects Versions: 3.0.0.Beta11 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 17:23:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 28 Mar 2017 17:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2537) ModelControllerMBeanTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reopened WFCORE-2537: ----------------------------------- Assignee: James Perkins (was: ehsavoie Hugonnet) Reopening as this one still seems to be failing. {code} mvn clean test -Dtest=ModelControllerMBeanTestCase -Dsecurity.manager ... ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.397 sec <<< FAILURE! - in org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase testDeploymentViaJmx(org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase) Time elapsed: 0.311 sec <<< ERROR! javax.management.ReflectionException: { "WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"javax.management.MBeanPermission\" \"org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]\" \"registerMBean\")\" in code source \"(vfs:/content/test-jmx.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx.jar\" from Service Module Loader\") Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"javax.management.MBeanPermission\" \"org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]\" \"registerMBean\")\" in code source \"(vfs:/content/test-jmx.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx.jar\" from Service Module Loader\")"}, "WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"] } at org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:513) at org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:459) at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:180) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731) at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) 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) Results : Tests in error: ModelControllerMBeanTestCase.testDeploymentViaJmx ? Reflection { "WFLYCTL0... Tests run: 3, Failures: 0, Errors: 1, Skipped: 0 {code} > ModelControllerMBeanTestCase fails with security manager in WF core > ------------------------------------------------------------------- > > Key: WFCORE-2537 > URL: https://issues.jboss.org/browse/WFCORE-2537 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > Fix For: 3.0.0.Beta11 > > > *org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase#testDeploymentViaJmx* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=ModelControllerMBeanTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:53:17,762 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]" "registerMBean")" in code source "(vfs:/content/test-jmx.jar )" of "ModuleClassLoader for Module "deployment.test-jmx.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]" "registerMBean")" in code source "(vfs:/content/test-jmx.jar )" of "ModuleClassLoader for Module "deployment.test-jmx.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 17:31:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Tue, 28 Mar 2017 17:31:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2451) CS tool, invalid content of --type parameter leads to NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned WFCORE-2451: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > CS tool, invalid content of --type parameter leads to NPE > --------------------------------------------------------- > > Key: WFCORE-2451 > URL: https://issues.jboss.org/browse/WFCORE-2451 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > > If I fill --type option with some invalid value (other then KeyStoreCredentialStore) I get NPE. For example with -t DoesNotExists I get > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary -t DoesNotExists > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 17:52:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 28 Mar 2017 17:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2536) JmxSensitiveTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reopened WFCORE-2536: ----------------------------------- Assignee: James Perkins (was: ehsavoie Hugonnet) Reopening as this still seems to have a failure with the security manager enabled {code} Failed tests: {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"javax.management.MBeanPermission\" \"org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]\" \"registerMBean\")\" in code source \"(vfs:/content/test-jmx-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-deployment.jar\" from Service Module Loader\") Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"javax.management.MBeanPermission\" \"org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]\" \"registerMBean\")\" in code source \"(vfs:/content/test-jmx-deployment.jar )\" of \"ModuleClassLoader for Module \"deployment.test-jmx-deployment.jar\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"]},"rolled-back" => true} {code} > JmxSensitiveTestCase fails with security manager in WF core > ----------------------------------------------------------- > > Key: WFCORE-2536 > URL: https://issues.jboss.org/browse/WFCORE-2536 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > Fix For: 3.0.0.Beta11 > > > *org.jboss.as.test.integration.mgmt.access.JmxSensitiveTestCase* > {{cd testsuite/rbac/}} > {{mvn test -Dtest=JmxSensitiveTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:42:13,573 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 18:21:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 28 Mar 2017 18:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2536) JmxSensitiveTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385501#comment-13385501 ] James Perkins commented on WFCORE-2536: --------------------------------------- I didn't look into it, but {{JmxSensitiveTestCase}} seems to require some test before it to execute otherwise it fails. I did not dig into why, but if anyone feels this is an issue please feel free to file a new JIRA. > JmxSensitiveTestCase fails with security manager in WF core > ----------------------------------------------------------- > > Key: WFCORE-2536 > URL: https://issues.jboss.org/browse/WFCORE-2536 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > Fix For: 3.0.0.Beta11 > > > *org.jboss.as.test.integration.mgmt.access.JmxSensitiveTestCase* > {{cd testsuite/rbac/}} > {{mvn test -Dtest=JmxSensitiveTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:42:13,573 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 18:25:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 28 Mar 2017 18:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2533) DeploymentRolloutFailureTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reassigned WFCORE-2533: ------------------------------------- Assignee: James Perkins > DeploymentRolloutFailureTestCase fails with security manager in WF core > ----------------------------------------------------------------------- > > Key: WFCORE-2533 > URL: https://issues.jboss.org/browse/WFCORE-2533 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > > *org.jboss.as.test.integration.domain.suites.DeploymentRolloutFailureTestCase#test* > {{cd testsuite/domain/}} > {{mvn test -Dtest=DeploymentRolloutFailureTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:main-three] 13:08:06,210 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "broken.jar" (runtime-name: "broken.jar") > [Server:main-three] 13:08:06,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service test.deployment.broken: org.jboss.msc.service.StartException in service test.deployment.broken: Failed to start service > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:main-three] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:main-three] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:main-three] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.broken.fail" "read")" in code source "(vfs:/content/broken.jar )" of "ModuleClassLoader for Module "deployment.broken.jar" from Service Module Loader") > [Server:main-three] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:main-three] at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:main-three] at java.lang.System.getProperty(System.java:443) [vm.jar:1.8.0] > [Server:main-three] at java.lang.System.getProperty(System.java:427) [vm.jar:1.8.0] > [Server:main-three] at java.lang.Boolean.getBoolean(Boolean.java:265) [rt.jar:1.8.0] > [Server:main-three] at org.jboss.as.test.integration.domain.deployment.broken.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:54) > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:main-three] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 18:45:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 28 Mar 2017 18:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8459) @TransactionAttribute should not be inherited per EJB 3.2 spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-9965 to WFLY-8459: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8459 (was: JBEAP-9965) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.0.4.GA) > @TransactionAttribute should not be inherited per EJB 3.2 spec > --------------------------------------------------------------- > > Key: WFLY-8459 > URL: https://issues.jboss.org/browse/WFLY-8459 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: JBoss EA P7.0.x > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > It appears that JBoss EAP behaves as the *@TransactionAttribute* attribute was inherited. > For example if I have a bean A that > {noformat} > @Stateless > @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) > public class ABean extends Base{ > > public void foo(){ . . .} > } > {noformat} > and a supper class > {noformat} > @TransactionAttribute(TransactionAttributeType.SUPPORTS) > public class Base { > > @TransactionAttribute(TransactionAttributeType.NEVER) > public void foo(){ . . } > public void bar(){ . . .} > } > {noformat} > and if I call each method > {noformat} > beanA.bar(); > beanA.foo(); > {noformat} > I would expect to see *bar()* without an active transaction and *foo()* with an active transaction > but what I see is that both method have no active transaction. This seems like spec violation since the *@TransactionAttribute* are not supposed to be inherited. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 19:02:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 28 Mar 2017 19:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reassigned WFCORE-2534: ------------------------------------- Assignee: James Perkins > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 19:10:00 2017 From: issues at jboss.org (Karl-Philipp Richter (JIRA)) Date: Tue, 28 Mar 2017 19:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8460) Improve feedback after invalid request for creating a datasource In-Reply-To: References: Message-ID: Karl-Philipp Richter created WFLY-8460: ------------------------------------------ Summary: Improve feedback after invalid request for creating a datasource Key: WFLY-8460 URL: https://issues.jboss.org/browse/WFLY-8460 Project: WildFly Issue Type: Enhancement Affects Versions: 10.1.0.Final Environment: Ubuntu 16.10 amd64 with OpenJDK 8 Reporter: Karl-Philipp Richter Assignee: Jason Greene After creating a Non-XA datasource in the web frontend and pressing finish on the last dialog page, I get the message "Unknown error" and the data entered into the form is lost. Clicking on "Unknown error" a dialog is displayed with the content ``` Unexpected HTTP response: 500 Request { "name" => "jdbc/linuxtracker2", "jta" => true, "enabled" => true, "user-name" => "APP", "password" => "APP", "jndi-name" => "java:/jdbc/linuxtracker2", "use-ccm" => true, "pool-name" => "jdbc/linuxtracker2_Pool", "connection-url" => "jdbc:derby://localhost:1527/derby-pool", "driver-class" => "org.apache.derby.jdbc.ClientDriver", "driver-name" => "jdbc/linuxtracker2", "operation" => "add", "address" => [ ("subsystem" => "datasources"), ("data-source" => "jdbc/linuxtracker2") ] } Response Internal Server Error { "outcome" => "failed", "failure-description" => { "WFLYCTL0412: Required services that are not installed:" => ["jboss.jdbc-driver.jdbc/linuxtracker2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "org.wildfly.data-source.jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]", "jboss.driver-demander.java:/jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]" ] }, "rolled-back" => true } ``` which is extremely unhelpful given the fact that an error message listing and explaining the cause for the failure could be displayed (e.g. "the datasource xy couldn't be created because the name doesn't match the requirement yz"). It's hard to guess that clicking on the "Unknown error" popup opens a dialog. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 19:14:00 2017 From: issues at jboss.org (Karl-Philipp Richter (JIRA)) Date: Tue, 28 Mar 2017 19:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8461) Improve feedback after invalid request for creating a datasource In-Reply-To: References: Message-ID: Karl-Philipp Richter created WFLY-8461: ------------------------------------------ Summary: Improve feedback after invalid request for creating a datasource Key: WFLY-8461 URL: https://issues.jboss.org/browse/WFLY-8461 Project: WildFly Issue Type: Enhancement Affects Versions: 10.1.0.Final Reporter: Karl-Philipp Richter Assignee: Jason Greene After creating a Non-XA datasource in the web frontend and pressing finish on the last dialog page, I get the message "Unknown error" and the data entered into the form is lost. Clicking on "Unknown error" a dialog is displayed with the content ``` Unexpected HTTP response: 500 Request { "name" => "jdbc/linuxtracker2", "jta" => true, "enabled" => true, "user-name" => "APP", "password" => "APP", "jndi-name" => "java:/jdbc/linuxtracker2", "use-ccm" => true, "pool-name" => "jdbc/linuxtracker2_Pool", "connection-url" => "jdbc:derby://localhost:1527/derby-pool", "driver-class" => "org.apache.derby.jdbc.ClientDriver", "driver-name" => "jdbc/linuxtracker2", "operation" => "add", "address" => [ ("subsystem" => "datasources"), ("data-source" => "jdbc/linuxtracker2") ] } Response Internal Server Error { "outcome" => "failed", "failure-description" => { "WFLYCTL0412: Required services that are not installed:" => ["jboss.jdbc-driver.jdbc/linuxtracker2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "org.wildfly.data-source.jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]", "jboss.driver-demander.java:/jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]" ] }, "rolled-back" => true } ``` which is extremely unhelpful given the fact that an error message listing and explaining the cause for the failure could be displayed (e.g. "the datasource xy couldn't be created because the name doesn't match the requirement yz"). It's hard to guess that clicking on the "Unknown error" popup opens a dialog. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 19:16:00 2017 From: issues at jboss.org (Karl-Philipp Richter (JIRA)) Date: Tue, 28 Mar 2017 19:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8462) Improve feedback after invalid request for creating a datasource In-Reply-To: References: Message-ID: Karl-Philipp Richter created WFLY-8462: ------------------------------------------ Summary: Improve feedback after invalid request for creating a datasource Key: WFLY-8462 URL: https://issues.jboss.org/browse/WFLY-8462 Project: WildFly Issue Type: Enhancement Affects Versions: 10.1.0.Final Reporter: Karl-Philipp Richter Assignee: Jason Greene After creating a Non-XA datasource in the web frontend and pressing finish on the last dialog page, I get the message "Unknown error" and the data entered into the form is lost. Clicking on "Unknown error" a dialog is displayed with the content ``` Unexpected HTTP response: 500 Request { "name" => "jdbc/linuxtracker2", "jta" => true, "enabled" => true, "user-name" => "APP", "password" => "APP", "jndi-name" => "java:/jdbc/linuxtracker2", "use-ccm" => true, "pool-name" => "jdbc/linuxtracker2_Pool", "connection-url" => "jdbc:derby://localhost:1527/derby-pool", "driver-class" => "org.apache.derby.jdbc.ClientDriver", "driver-name" => "jdbc/linuxtracker2", "operation" => "add", "address" => [ ("subsystem" => "datasources"), ("data-source" => "jdbc/linuxtracker2") ] } Response Internal Server Error { "outcome" => "failed", "failure-description" => { "WFLYCTL0412: Required services that are not installed:" => ["jboss.jdbc-driver.jdbc/linuxtracker2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "org.wildfly.data-source.jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]", "jboss.driver-demander.java:/jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]" ] }, "rolled-back" => true } ``` which is extremely unhelpful given the fact that an error message listing and explaining the cause for the failure could be displayed (e.g. "the datasource xy couldn't be created because the name doesn't match the requirement yz"). It's hard to guess that clicking on the "Unknown error" popup opens a dialog. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 28 20:34:00 2017 From: issues at jboss.org (Chao Wang (JIRA)) Date: Tue, 28 Mar 2017 20:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chao Wang updated WFLY-8458: ---------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9860, https://github.com/wildfly/wildfly/pull/9864 (was: https://github.com/wildfly/wildfly/pull/9860) > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 11.0.0.Beta1 > > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 02:06:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 29 Mar 2017 02:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2165) TP.receive() should also handle InputStreams In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385545#comment-13385545 ] Bela Ban commented on JGRP-2165: -------------------------------- This change had wider implications that simply adding {{receive(InputStream)}} to {{TP}}: any class extending {{org.jgroups.blocks.cs.ReceiverAdapter}} and wanting to handle both TCP_NIO2 and TCP had to implement both {{receive(InputStream)}} (TCP) _and_ {{receive(byte[])}} (TCP_NIO2). This required a common protocol format (e.g. length first) for both TCP and TCP_NIO2. Affected classes included PubServer, PubClient, GossipRouter and RouterStub (used by TCPGOSSIP and TUNNEL). > TP.receive() should also handle InputStreams > -------------------------------------------- > > Key: JGRP-2165 > URL: https://issues.jboss.org/browse/JGRP-2165 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.2 > > > Currently, {{TP.receive()}} is passed a byte[] buffer as parameter. This is OK for UDP and TCP_NIO2, however, in TCP we're dealing with a socket input stream. > TcpConnection reads the length, then copies {{length}} bytes into a byte[] buffer and finally calls TP.receive() with the byte[] buffer as argument. > The byte[] buffer and the copying of read data into it is superfluous if TP.receive() could also accept input streams as argument. > Therefore introduce an additional {{TP.receive(InputStream in, int offset, int length}}, which reads directly from the socket's input stream and gets rid of the intermediate byte buffer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:20:00 2017 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 29 Mar 2017 03:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-2165) TP.receive() should also handle InputStreams In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-2165. ---------------------------- Resolution: Done > TP.receive() should also handle InputStreams > -------------------------------------------- > > Key: JGRP-2165 > URL: https://issues.jboss.org/browse/JGRP-2165 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.2 > > > Currently, {{TP.receive()}} is passed a byte[] buffer as parameter. This is OK for UDP and TCP_NIO2, however, in TCP we're dealing with a socket input stream. > TcpConnection reads the length, then copies {{length}} bytes into a byte[] buffer and finally calls TP.receive() with the byte[] buffer as argument. > The byte[] buffer and the copying of read data into it is superfluous if TP.receive() could also accept input streams as argument. > Therefore introduce an additional {{TP.receive(InputStream in, int offset, int length}}, which reads directly from the socket's input stream and gets rid of the intermediate byte buffer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:36:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Wed, 29 Mar 2017 03:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1039) Fix copyright header in ModuleLoader class In-Reply-To: References: Message-ID: Josef Cacek created ELY-1039: -------------------------------- Summary: Fix copyright header in ModuleLoader class Key: ELY-1039 URL: https://issues.jboss.org/browse/ELY-1039 Project: WildFly Elytron Issue Type: Bug Affects Versions: 1.1.0.Beta32 Reporter: Josef Cacek Assignee: Josef Cacek ModuleLoader class has LGPL header. Let's fix it and use the project default ASL header. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:38:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 29 Mar 2017 03:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-77) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan deleted HAWKULARQE-77: ------------------------------------- > Manual Testcases - Create and Run > --------------------------------- > > Key: HAWKULARQE-77 > URL: https://issues.jboss.org/browse/HAWKULARQE-77 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:38:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 29 Mar 2017 03:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-78) Automate Testcases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan deleted HAWKULARQE-78: ------------------------------------- > Automate Testcases > ------------------ > > Key: HAWKULARQE-78 > URL: https://issues.jboss.org/browse/HAWKULARQE-78 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:38:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 29 Mar 2017 03:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-76) Add Provider - Security Protocol In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan deleted HAWKULARQE-76: ------------------------------------- > Add Provider - Security Protocol > -------------------------------- > > Key: HAWKULARQE-76 > URL: https://issues.jboss.org/browse/HAWKULARQE-76 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > Priority: Critical > > In Add New Provider page there is a new field: "Security Protocol", for validating connection. > It needs to be tested and automated in Provider CRUD tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:38:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 29 Mar 2017 03:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-33) [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-33: ---------------------------------------- Assignee: Hayk Hovsepyan (was: Vojtech Prusa) > [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider > ------------------------------------------------------------- > > Key: HAWKULARQE-33 > URL: https://issues.jboss.org/browse/HAWKULARQE-33 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > Labels: mm-integration-hawkular-qe > > See [JMAN4-188|https://issues.jboss.org/browse/JMAN4-188] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 03:39:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Wed, 29 Mar 2017 03:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-33) [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-33: ---------------------------------------- Assignee: Prachi Yadav (was: Hayk Hovsepyan) > [QE] - JMAN4-188 - Secure link from CloudForms to MW Provider > ------------------------------------------------------------- > > Key: HAWKULARQE-33 > URL: https://issues.jboss.org/browse/HAWKULARQE-33 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > Priority: Critical > Labels: mm-integration-hawkular-qe > > See [JMAN4-188|https://issues.jboss.org/browse/JMAN4-188] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 04:26:00 2017 From: issues at jboss.org (Martin Simka (JIRA)) Date: Wed, 29 Mar 2017 04:26:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8045) test suite can't start server when -Ddebug is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Simka updated WFLY-8045: ------------------------------- Workaround Description: mvn clean test -Dcheckstyle.skip -Denforcer.skip -DtestLogToFile=false "-Djvm.args.other=-server -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y" -Dtest=SPNEGOLoginModuleTestCase Workaround: Workaround Exists > test suite can't start server when -Ddebug is used > -------------------------------------------------- > > Key: WFLY-8045 > URL: https://issues.jboss.org/browse/WFLY-8045 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Martin Simka > > Running tests from test suite with -Ddebug fails with > {noformat} > Listening for transport dt_socket at address: 8787 > 13:16:26,941 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 13:16:26,950 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/usr/lib/jvm/jdk-8-oracle-x64/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y, -Djboss.dist=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/../../../dist/target/wildfly-11.0.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -server, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic, -Djbossas.ts.integ.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/.., -Djbossas.ts.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/../.., -Djbossas.project.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/../../.., -Djava.io.tmpdir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target, -Djboss.inst=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas, -Dtest.bind.address=127.0.0.1, -ea, -Djboss.home.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas, -Dorg.jboss.boot.log.file=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/standalone/configuration/logging.properties, -jar, /home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/jboss-modules.jar, -mp, /home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/modules:/home/msimka/Projekty/redhat/git/wildfly/dist/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules:/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas, -Djboss.server.base.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/standalone, -Djboss.server.log.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/standalone/log, -Djboss.server.config.dir=/home/msimka/Projekty/redhat/git/wildfly/testsuite/integration/basic/target/jbossas/standalone/configuration, -Dts.wildfly.version=11.0.0.Alpha1-SNAPSHOT, -c=standalone-full.xml] > Listening for transport dt_socket at address: 8787 > 13:16:27,141 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta15 > 13:16:27,162 INFO [org.xnio] (main) XNIO version 3.4.3.Final > 13:16:27,180 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final > 13:16:27,289 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta22 > Running org.jboss.as.test.integration.security.credentialreference.CredentialReferenceDatasourceTestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.01 sec <<< FAILURE! - in org.jboss.as.test.integration.security.credentialreference.CredentialReferenceDatasourceTestCase > org.jboss.as.test.integration.security.credentialreference.CredentialReferenceDatasourceTestCase Time elapsed: 0.009 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:168) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:115) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:116) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [60] s > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:161) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:115) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:116) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103 > {noformat} > when setting suspend=n and and printing exception details in [ManagedDeployableContainer.java#L231|https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L231] it shows java.net.BindException: Address already in use > {noformat} > 13:23:25,488 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Waiting on port 8787 to become available for 5s > java.net.BindException: Address already in use > at java.net.PlainSocketImpl.socketBind(Native Method) > at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) > at java.net.ServerSocket.bind(ServerSocket.java:375) > at java.net.ServerSocket.(ServerSocket.java:237) > at java.net.ServerSocket.(ServerSocket.java:128) > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.isPortAvailable(ManagedDeployableContainer.java:223) > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.waitOnPorts(ManagedDeployableContainer.java:189) > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:133) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:115) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:116) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 04:37:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 29 Mar 2017 04:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8463) Elytron, misconfiguration of http-authentication-factory leads to 403 - should be 500 In-Reply-To: References: Message-ID: Martin Choma created WFLY-8463: ---------------------------------- Summary: Elytron, misconfiguration of http-authentication-factory leads to 403 - should be 500 Key: WFLY-8463 URL: https://issues.jboss.org/browse/WFLY-8463 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse When I misconfigured {{http-authentication-factory}, e.g. with unreal protocol "DOES_NOT_EXIST" I get http status code 403. I think 500 would be more appropriate here, as server is misconfigured and can't authenticate. 403 means user has not appropriate roles. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 04:37:01 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 29 Mar 2017 04:37:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8463) Elytron, misconfiguration of http-authentication-factory leads to 403 - should be 500 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFLY-8463: ------------------------------- Steps to Reproduce: * Follow steps for securing management interface with kerberos https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1.alpha/html-single/how_to_set_up_sso_with_kerberos/#secure_mgmt_interface_krb_elytron * Replace creation of http-authentication-factory with this command specifying protocol HTTP {code} /subsystem=elytron/http-authentication-factory=example-krb-http-auth:add( \ http-server-mechanism-factory=global, \ security-domain=exampleFsSD, \ mechanism-configurations=[ \ { \ mechanism-name=SPNEGO,\ mechanism-realm-configurations= \ [ \ { \ realm-name=exampleFsSD \ } \ ], \ protocol=DOES_NOT_EXIST,\ credential-security-factory=krbSF \ } \ ] \ ) {code} was: /subsystem=elytron/http-authentication-factory=example-krb-http-auth:add( \ http-server-mechanism-factory=global, \ security-domain=exampleFsSD, \ mechanism-configurations=[ \ { \ mechanism-name=SPNEGO,\ mechanism-realm-configurations= \ [ \ { \ realm-name=exampleFsSD \ } \ ], \ protocol=DOES_NOT_EXIST,\ credential-security-factory=krbSF \ } \ ] \ ) > Elytron, misconfiguration of http-authentication-factory leads to 403 - should be 500 > ------------------------------------------------------------------------------------- > > Key: WFLY-8463 > URL: https://issues.jboss.org/browse/WFLY-8463 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > When I misconfigured {{http-authentication-factory}, e.g. with unreal protocol "DOES_NOT_EXIST" I get http status code 403. > I think 500 would be more appropriate here, as server is misconfigured and can't authenticate. > 403 means user has not appropriate roles. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 04:38:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 29 Mar 2017 04:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8463) Elytron, misconfiguration of http-authentication-factory leads to 403 - should be 500 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Choma updated WFLY-8463: ------------------------------- Description: When I misconfigured {{http-authentication-factory}}, e.g. with unreal protocol "DOES_NOT_EXIST" I get http status code 403. I think 500 would be more appropriate here, as server is misconfigured and can't authenticate. 403 means user has not appropriate roles. In log there is {code} 10:08:06,309 TRACE [org.wildfly.security] (management task-6) java.lang.IllegalStateException: ELY01119: Unable to resolve MechanismConfiguration for mechanismType='HTTP', mechanismName='SPNEGO', hostName='localhost.localdomain', protocol='http'. {code} was: When I misconfigured {{http-authentication-factory}, e.g. with unreal protocol "DOES_NOT_EXIST" I get http status code 403. I think 500 would be more appropriate here, as server is misconfigured and can't authenticate. 403 means user has not appropriate roles. > Elytron, misconfiguration of http-authentication-factory leads to 403 - should be 500 > ------------------------------------------------------------------------------------- > > Key: WFLY-8463 > URL: https://issues.jboss.org/browse/WFLY-8463 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > When I misconfigured {{http-authentication-factory}}, e.g. with unreal protocol "DOES_NOT_EXIST" I get http status code 403. > I think 500 would be more appropriate here, as server is misconfigured and can't authenticate. > 403 means user has not appropriate roles. > In log there is > {code} > 10:08:06,309 TRACE [org.wildfly.security] (management task-6) java.lang.IllegalStateException: ELY01119: Unable to resolve MechanismConfiguration for mechanismType='HTTP', mechanismName='SPNEGO', hostName='localhost.localdomain', protocol='http'. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 05:30:00 2017 From: issues at jboss.org (Karl-Philipp Richter (JIRA)) Date: Wed, 29 Mar 2017 05:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8464) Add return and shutdown controls to web frontend In-Reply-To: References: Message-ID: Karl-Philipp Richter created WFLY-8464: ------------------------------------------ Summary: Add return and shutdown controls to web frontend Key: WFLY-8464 URL: https://issues.jboss.org/browse/WFLY-8464 Project: WildFly Issue Type: Feature Request Components: Web Console Affects Versions: 10.1.0.Final Reporter: Karl-Philipp Richter Assignee: Harald Pehl It'd be nice to have controls for shutting down and restarting the server in the web frontend. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 05:43:03 2017 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Wed, 29 Mar 2017 05:43:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8465) Upgrade RESTEasy to 3.0.22.Final In-Reply-To: References: Message-ID: Alessio Soldano created WFLY-8465: ------------------------------------- Summary: Upgrade RESTEasy to 3.0.22.Final Key: WFLY-8465 URL: https://issues.jboss.org/browse/WFLY-8465 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 06:28:00 2017 From: issues at jboss.org (=?UTF-8?Q?Ivo_Hr=C3=A1dek_=28JIRA=29?=) Date: Wed, 29 Mar 2017 06:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2023) Log viewer does not show any log file for rpm installation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Hr?dek reassigned WFCORE-2023: ---------------------------------- Assignee: Ivo Hr?dek (was: Bartosz Baranowski) > Log viewer does not show any log file for rpm installation > ---------------------------------------------------------- > > Key: WFCORE-2023 > URL: https://issues.jboss.org/browse/WFCORE-2023 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Bartosz Baranowski > Assignee: Ivo Hr?dek > > I'm running a fresh RHEL7.3 server subscribed to the current jboss eap7 repository [1] using the rpm package. [2] > [1] subscription-manager repos --enable=jb-eap-7-for-rhel-RHEL_VERSION-server-rpms > [2] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/installation-guide/#rpm_installation -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 06:28:00 2017 From: issues at jboss.org (=?UTF-8?Q?Ivo_Hr=C3=A1dek_=28JIRA=29?=) Date: Wed, 29 Mar 2017 06:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2023) Log viewer does not show any log file for rpm installation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Hr?dek resolved WFCORE-2023. -------------------------------- Resolution: Done > Log viewer does not show any log file for rpm installation > ---------------------------------------------------------- > > Key: WFCORE-2023 > URL: https://issues.jboss.org/browse/WFCORE-2023 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Bartosz Baranowski > Assignee: Ivo Hr?dek > > I'm running a fresh RHEL7.3 server subscribed to the current jboss eap7 repository [1] using the rpm package. [2] > [1] subscription-manager repos --enable=jb-eap-7-for-rhel-RHEL_VERSION-server-rpms > [2] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/installation-guide/#rpm_installation -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 06:39:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Wed, 29 Mar 2017 06:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1040) Elytron, incorrect IPv6 address resolution In-Reply-To: References: Message-ID: Martin Choma created ELY-1040: --------------------------------- Summary: Elytron, incorrect IPv6 address resolution Key: ELY-1040 URL: https://issues.jboss.org/browse/ELY-1040 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical There is code in Elytron {code:java|title=SetMechanismInformationMechanismFactory.java} @Override public void evaluateRequest(HttpServerRequest request) throws HttpAuthenticationException { String host = request.getFirstRequestHeaderValue(HOST); String resolvedHostName = null; if (host != null) { if (host.startsWith("[")) { int close = host.indexOf(']'); if (close > 0) { resolvedHostName = host.substring(0, close); } } {code} I assume intention of this code is to get from e.g. "[::1]:8080" just "[::1]", but now it gets only "[::1". To achieve this my assumption, there should be rather {code} resolvedHostName = host.substring(0, close + 1); {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 06:43:00 2017 From: issues at jboss.org (Ingo Weiss (JIRA)) Date: Wed, 29 Mar 2017 06:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Weiss updated JBJCA-1341: ------------------------------ Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/622, https://github.com/ironjacamar/ironjacamar/pull/621, https://github.com/ironjacamar/ironjacamar/pull/620, https://github.com/ironjacamar/ironjacamar/pull/613, https://github.com/ironjacamar/ironjacamar/pull/612, https://github.com/ironjacamar/ironjacamar/pull/611, https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607, https://github.com/ironjacamar/ironjacamar/pull/608 (was: https://github.com/ironjacamar/ironjacamar/pull/613, https://github.com/ironjacamar/ironjacamar/pull/612, https://github.com/ironjacamar/ironjacamar/pull/611, https://github.com/ironjacamar/ironjacamar/pull/606, https://github.com/ironjacamar/ironjacamar/pull/607, https://github.com/ironjacamar/ironjacamar/pull/608) > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 07:05:00 2017 From: issues at jboss.org (Johannes Ritter (JIRA)) Date: Wed, 29 Mar 2017 07:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response In-Reply-To: References: Message-ID: Johannes Ritter created WFLY-8466: ------------------------------------- Summary: Socket leak when setting HTTP Content-Length and client not reading entire response Key: WFLY-8466 URL: https://issues.jboss.org/browse/WFLY-8466 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.1.0.Final Environment: CentOS 6.7 Reporter: Johannes Ritter Assignee: Stuart Douglas Attachments: socket_leak.tar.gz Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set. The leaked sockets can be determined by "lsof -p | grep identify". The relevant sockets are listed with "Can't identify protocol". The leak occurs if the client connection is closed (on the client side) before the server could send the complete response. It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click. *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 07:07:00 2017 From: issues at jboss.org (Johannes Ritter (JIRA)) Date: Wed, 29 Mar 2017 07:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385801#comment-13385801 ] Johannes Ritter commented on WFLY-8466: --------------------------------------- Probably related to this issue. > Socket leak when setting HTTP Content-Length and client not reading entire response > ----------------------------------------------------------------------------------- > > Key: WFLY-8466 > URL: https://issues.jboss.org/browse/WFLY-8466 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: CentOS 6.7 > Reporter: Johannes Ritter > Assignee: Stuart Douglas > Labels: leak, socket > Attachments: socket_leak.tar.gz > > > Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set. > The leaked sockets can be determined by "lsof -p | grep identify". The relevant sockets are listed with "Can't identify protocol". > The leak occurs if the client connection is closed (on the client side) before the server could send the complete response. > It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click. > *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 07:53:01 2017 From: issues at jboss.org (Richard Opalka (JIRA)) Date: Wed, 29 Mar 2017 07:53:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2588) Deprecate optional dependencies in manifests and descriptors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Opalka closed WFCORE-2588. ---------------------------------- Resolution: Rejected After comments on associated PR from WildFly folks I'm closing this issue. The optional module dependencies will be worked around in DU processing chain. > Deprecate optional dependencies in manifests and descriptors > ------------------------------------------------------------ > > Key: WFCORE-2588 > URL: https://issues.jboss.org/browse/WFCORE-2588 > Project: WildFly Core > Issue Type: Enhancement > Affects Versions: 3.0.0.Beta11 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 09:14:00 2017 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Wed, 29 Mar 2017 09:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1041) Add support for PKCS11 in KeyStoreCredentialStore In-Reply-To: References: Message-ID: Peter Skopek created ELY-1041: --------------------------------- Summary: Add support for PKCS11 in KeyStoreCredentialStore Key: ELY-1041 URL: https://issues.jboss.org/browse/ELY-1041 Project: WildFly Elytron Issue Type: Task Components: Credential Store Reporter: Peter Skopek Assignee: Peter Skopek To be able to use KeyStoreCredentialStore in FIPS mode we need to have support for working with SecretKey stored in PKCS11 credential store. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 09:18:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 29 Mar 2017 09:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2488) Elytron keystore type default value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev closed WFCORE-2488. --------------------------------- Release Notes Text: JBEAP-8508 was closed Resolution: Rejected > Elytron keystore type default value > ----------------------------------- > > Key: WFCORE-2488 > URL: https://issues.jboss.org/browse/WFCORE-2488 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Make attribute type optional during key-store creation. If not set default value "JKS" can be used. > Basically in this issue is requesting same behaviour as legacy keystore in realms > {code:jsonl|title=ManagementModel} > "keystore-provider" => { > "type" => STRING, > "description" => "The provider for loading the keystore, defaults to JKS.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => "JKS", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > Extracted from WFLY-7125 and tracked as separate issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 09:32:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 29 Mar 2017 09:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8467) simple-election-policy is not sufficiently descriptive In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-8467: ---------------------------------- Summary: simple-election-policy is not sufficiently descriptive Key: WFLY-8467 URL: https://issues.jboss.org/browse/WFLY-8467 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 11.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 12.0.0.Alpha1 simple-election-policy was originally a port of http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/main/java/org/jboss/ha/singleton/HASingletonElectionPolicySimple.java It's time to revisit this. 1. The term "simple" doesn't at all describe how the policy elects the primary node. 2. "position" isn't intuitive either - until you realize that it is a reference to the underlying data structure. 3. Is the ability to specify the nth youngest or oldest node a realistic requirement? We can generalize this policy as doing 2 things: a. Sorts the candidates based on some criteria (e.g. age, name) b. Select the head of the sorted list This is logically equivalent to: members.stream().sort(comparator).findFirst(); Proposal: -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 09:38:00 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Wed, 29 Mar 2017 09:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2451) CS tool, invalid content of --type parameter leads to NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385949#comment-13385949 ] Ilia Vassilev commented on WFCORE-2451: --------------------------------------- This issue is resolved by PR [1] for WFCORE-2484 which will display the complete stack trace of the underlying exception. [1] https://github.com/wildfly-security/wildfly-elytron-tool/pull/23 > CS tool, invalid content of --type parameter leads to NPE > --------------------------------------------------------- > > Key: WFCORE-2451 > URL: https://issues.jboss.org/browse/WFCORE-2451 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > > If I fill --type option with some invalid value (other then KeyStoreCredentialStore) I get NPE. For example with -t DoesNotExists I get > {code} > [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="/tmp/test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary -t DoesNotExists > Exception in thread "main" java.lang.NullPointerException > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) > at java.util.regex.Matcher.reset(Matcher.java:309) > at java.util.regex.Matcher.(Matcher.java:229) > at java.util.regex.Pattern.matcher(Pattern.java:1093) > at java.util.Formatter.parse(Formatter.java:2547) > at java.util.Formatter.format(Formatter.java:2501) > at java.io.PrintStream.format(PrintStream.java:970) > at java.io.PrintStream.printf(PrintStream.java:871) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:28:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 29 Mar 2017 10:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1042) When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1042: --------------------------------- Summary: When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. Key: ELY-1042 URL: https://issues.jboss.org/browse/ELY-1042 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Priority: Critical When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. I expect consistent state, same aliases in memory and persisted on disk. We must not add new aliases only to memory. This problem is exported from issue https://issues.jboss.org/browse/JBEAP-6866 where is noted as secondary problem. *HOW TO REPRODUCE* {code} /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/credentialstore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to="jboss.server.data.dir") {code} {code} /subsystem=elytron/credential-store=cs001/alias=alias001:add(secret-value=secretvalue) {code} Now is credentialstore.jceks file persisted on disk here *JBOSS_HOME/standalone/data/cs* Please remove write permission for folder "cs" {code} chmod g-w cs chmod u-w cs {code} Try add another entry to credential store /subsystem=elytron/credential-store=cs001/alias=alias002:add(secret-value=secretvalue) { "outcome" => "failed", "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09525: Unable to flush credential store to storage'", "rolled-back" => true } And you get error message as above. Now you list all aliases in credential store: {code} /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) { "outcome" => "success", "result" => [ "alias001", "alias002" ] } {code} There is non persisted "alias002" too. *Now we check aliases in persisted file:* {code} reload {code} There isn't any alias "alias002" after reload. {code} /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) { "outcome" => "success", "result" => ["alias001"] } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:28:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 29 Mar 2017 10:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1042) When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1042: ------------------------------ Component/s: Credential Store > When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1042 > URL: https://issues.jboss.org/browse/ELY-1042 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Critical > > When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. > I expect consistent state, same aliases in memory and persisted on disk. > We must not add new aliases only to memory. > This problem is exported from issue https://issues.jboss.org/browse/JBEAP-6866 > where is noted as secondary problem. > *HOW TO REPRODUCE* > {code} > /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/credentialstore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to="jboss.server.data.dir") > {code} > {code} > /subsystem=elytron/credential-store=cs001/alias=alias001:add(secret-value=secretvalue) > {code} > Now is credentialstore.jceks file persisted on disk here *JBOSS_HOME/standalone/data/cs* > Please remove write permission for folder "cs" > {code} > chmod g-w cs > chmod u-w cs > {code} > Try add another entry to credential store > /subsystem=elytron/credential-store=cs001/alias=alias002:add(secret-value=secretvalue) > { > "outcome" => "failed", > "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09525: Unable to flush credential store to storage'", > "rolled-back" => true > } > And you get error message as above. > Now you list all aliases in credential store: > {code} > /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) > { > "outcome" => "success", > "result" => [ > "alias001", > "alias002" > ] > } > {code} > There is non persisted "alias002" too. > *Now we check aliases in persisted file:* > {code} > reload > {code} > There isn't any alias "alias002" after reload. > {code} > /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) > { > "outcome" => "success", > "result" => ["alias001"] > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:30:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Wed, 29 Mar 2017 10:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1042) When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1042: ------------------------------ Description: When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. I expect consistent state, same aliases in memory and persisted on disk. We must not add new aliases only to memory. This problem is exported from issue https://issues.jboss.org/browse/JBEAP-6866 where is noted as secondary problem. *HOW TO REPRODUCE* {code} /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/credentialstore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to="jboss.server.data.dir") {code} {code} /subsystem=elytron/credential-store=cs001/alias=alias001:add(secret-value=secretvalue) {code} Now is credentialstore.jceks file persisted on disk here *JBOSS_HOME/standalone/data/cs* Please remove write permission for folder "cs" {code} chmod g-w cs chmod u-w cs {code} Try add another entry to credential store /subsystem=elytron/credential-store=cs001/alias=alias002:add(secret-value=secretvalue) { "outcome" => "failed", "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09525: Unable to flush credential store to storage'", "rolled-back" => true } And you get error message as above. Now you list all aliases in credential store: {code} /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) { "outcome" => "success", "result" => [ "alias001", "alias002" ] } {code} There is non persisted "alias002" too. *Now we check aliases in persisted file**:* {code} reload {code} There isn't any alias "alias002" after reload. {code} /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) { "outcome" => "success", "result" => ["alias001"] } {code} was: When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. I expect consistent state, same aliases in memory and persisted on disk. We must not add new aliases only to memory. This problem is exported from issue https://issues.jboss.org/browse/JBEAP-6866 where is noted as secondary problem. *HOW TO REPRODUCE* {code} /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/credentialstore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to="jboss.server.data.dir") {code} {code} /subsystem=elytron/credential-store=cs001/alias=alias001:add(secret-value=secretvalue) {code} Now is credentialstore.jceks file persisted on disk here *JBOSS_HOME/standalone/data/cs* Please remove write permission for folder "cs" {code} chmod g-w cs chmod u-w cs {code} Try add another entry to credential store /subsystem=elytron/credential-store=cs001/alias=alias002:add(secret-value=secretvalue) { "outcome" => "failed", "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09525: Unable to flush credential store to storage'", "rolled-back" => true } And you get error message as above. Now you list all aliases in credential store: {code} /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) { "outcome" => "success", "result" => [ "alias001", "alias002" ] } {code} There is non persisted "alias002" too. *Now we check aliases in persisted file:* {code} reload {code} There isn't any alias "alias002" after reload. {code} /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) { "outcome" => "success", "result" => ["alias001"] } {code} > When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1042 > URL: https://issues.jboss.org/browse/ELY-1042 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Critical > > When failed credential store flush to file on the disk then we have inconsistency between credential store in memory and persisted file. > I expect consistent state, same aliases in memory and persisted on disk. > We must not add new aliases only to memory. > This problem is exported from issue https://issues.jboss.org/browse/JBEAP-6866 > where is noted as secondary problem. > *HOW TO REPRODUCE* > {code} > /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/credentialstore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to="jboss.server.data.dir") > {code} > {code} > /subsystem=elytron/credential-store=cs001/alias=alias001:add(secret-value=secretvalue) > {code} > Now is credentialstore.jceks file persisted on disk here *JBOSS_HOME/standalone/data/cs* > Please remove write permission for folder "cs" > {code} > chmod g-w cs > chmod u-w cs > {code} > Try add another entry to credential store > /subsystem=elytron/credential-store=cs001/alias=alias002:add(secret-value=secretvalue) > { > "outcome" => "failed", > "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09525: Unable to flush credential store to storage'", > "rolled-back" => true > } > And you get error message as above. > Now you list all aliases in credential store: > {code} > /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) > { > "outcome" => "success", > "result" => [ > "alias001", > "alias002" > ] > } > {code} > There is non persisted "alias002" too. > *Now we check aliases in persisted file**:* > {code} > reload > {code} > There isn't any alias "alias002" after reload. > {code} > /subsystem=elytron/credential-store=cs001:read-children-names(child-type=alias) > { > "outcome" => "success", > "result" => ["alias001"] > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:33:01 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Wed, 29 Mar 2017 10:33:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1502) Incorrect "local" namespace resolution In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1502: -------------------------------------- Summary: Incorrect "local" namespace resolution Key: DROOLS-1502 URL: https://issues.jboss.org/browse/DROOLS-1502 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: {code:xml} feel:string "a","b","c" MyInput - "Decision taken" {code} and it's throwing two distinct types of NPEs.. (follows) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:38:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Wed, 29 Mar 2017 10:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1502) Incorrect "local" namespace resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386023#comment-13386023 ] Matteo Mortari commented on DROOLS-1502: ---------------------------------------- First problem is {{DMNCompilerImpl.resolveTypeRef()}} which was not considering local namespace for the QName as resolved by the unmarshalling {code:java} 16:28:24.122 [main] ERROR o.k.d.core.compiler.DMNCompilerImpl.compile:78 - Error compiling model from source. java.lang.NullPointerException: null at org.kie.dmn.core.compiler.DMNCompilerImpl.resolveTypeRef(DMNCompilerImpl.java:398) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.buildTypeDef(DMNCompilerImpl.java:290) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.processItemDefinitions(DMNCompilerImpl.java:100) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:90) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:75) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:64) [classes/:na] at org.kie.dmn.core.assembler.DMNAssemblerService.addResource(DMNAssemblerService.java:55) [classes/:na] {code} > Incorrect "local" namespace resolution > -------------------------------------- > > Key: DROOLS-1502 > URL: https://issues.jboss.org/browse/DROOLS-1502 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: > {code:xml} > > name="definitions" > namespace="https://www.drools.org/kie-dmn/definitions" > xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" > xmlns:kie="https://www.drools.org/kie-dmn" > > > > > feel:string > > "a","b","c" > > > > > > > > > > > > > > MyInput > > > > > > - > > > "Decision taken" > > > > > > {code} > and it's throwing two distinct types of NPEs.. (follows) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:43:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Wed, 29 Mar 2017 10:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1502) Incorrect "local" namespace resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386024#comment-13386024 ] Matteo Mortari commented on DROOLS-1502: ---------------------------------------- Second problem is {{DMNEvaluatorCompiler.compileDecisionTable}} was using wrong "baseline" node for local namespace resolution when calling {{resolveType}} for the InputClause {code:java} 16:38:02.061 [main] ERROR o.k.d.core.compiler.DMNCompilerImpl.compile:80 - Error compiling model from source. java.lang.NullPointerException: null at org.kie.dmn.core.compiler.DMNEvaluatorCompiler.compileDecisionTable(DMNEvaluatorCompiler.java:254) ~[classes/:na] at org.kie.dmn.core.compiler.DMNEvaluatorCompiler.compileExpression(DMNEvaluatorCompiler.java:75) ~[classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.processDrgElements(DMNCompilerImpl.java:207) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:93) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:77) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:66) [classes/:na] at org.kie.dmn.core.assembler.DMNAssemblerService.addResource(DMNAssemblerService.java:55) [classes/:na] {code} > Incorrect "local" namespace resolution > -------------------------------------- > > Key: DROOLS-1502 > URL: https://issues.jboss.org/browse/DROOLS-1502 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: > {code:xml} > > name="definitions" > namespace="https://www.drools.org/kie-dmn/definitions" > xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" > xmlns:kie="https://www.drools.org/kie-dmn" > > > > > feel:string > > "a","b","c" > > > > > > > > > > > > > > MyInput > > > > > > - > > > "Decision taken" > > > > > > {code} > and it's throwing two distinct types of NPEs.. (follows) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:45:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 10:45:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) 2nd baselines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen resolved HAWKULARQE-74. ----------------------------------- Resolution: Done > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:46:01 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 10:46:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-74) Baseline #2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-74: ---------------------------------- Summary: Baseline #2 (was: 2nd baselines) > Baseline #2 > ----------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png, 30minutes-raw.txt.zip > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:48:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 10:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-81) Baseline #3 In-Reply-To: References: Message-ID: viet nguyen created HAWKULARQE-81: ------------------------------------- Summary: Baseline #3 Key: HAWKULARQE-81 URL: https://issues.jboss.org/browse/HAWKULARQE-81 Project: Hawkular QE Issue Type: Sub-task Reporter: viet nguyen Assignee: Michael Foley * Run pyme on master to eliminate vpn slowness * Fix query start-end window * Update pyme endpoint to increase metrics to 30 (currently 2) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 10:48:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 10:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-81) Baseline #3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen reassigned HAWKULARQE-81: ------------------------------------- Assignee: viet nguyen (was: Michael Foley) > Baseline #3 > ----------- > > Key: HAWKULARQE-81 > URL: https://issues.jboss.org/browse/HAWKULARQE-81 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > * Run pyme on master to eliminate vpn slowness > * Fix query start-end window > * Update pyme endpoint to increase metrics to 30 (currently 2) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 11:11:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 29 Mar 2017 11:11:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2594) NullPointerException when removing configuration history In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2594: ---------------------------------------- Summary: NullPointerException when removing configuration history Key: WFCORE-2594 URL: https://issues.jboss.org/browse/WFCORE-2594 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.Final Reporter: Dennis Reed Assignee: Ken Wills Fix For: 3.0.0.Beta12 org.jboss.as.controller.persistence.ConfigurationFile#deleteRecursively is missing error checking. If an I/O error occurs while listing the directory contents (file permission error/etc) it still tries to use the listing and gets a NullPointerException. This method is used while removing old configuration history directories during boot, and the NullPointerException causes the EAP boot to abort. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 11:21:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 29 Mar 2017 11:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2537) ModelControllerMBeanTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2537: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > ModelControllerMBeanTestCase fails with security manager in WF core > ------------------------------------------------------------------- > > Key: WFCORE-2537 > URL: https://issues.jboss.org/browse/WFCORE-2537 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > Fix For: 3.0.0.Beta12 > > > *org.jboss.as.test.integration.jmx.ModelControllerMBeanTestCase#testDeploymentViaJmx* > {{cd testsuite/standalone/}} > {{mvn test -Dtest=ModelControllerMBeanTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:53:17,762 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]" "registerMBean")" in code source "(vfs:/content/test-jmx.jar )" of "ModuleClassLoader for Module "deployment.test-jmx.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=test-jmx.jar]" "registerMBean")" in code source "(vfs:/content/test-jmx.jar )" of "ModuleClassLoader for Module "deployment.test-jmx.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 11:21:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 29 Mar 2017 11:21:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2536) JmxSensitiveTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2536: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > JmxSensitiveTestCase fails with security manager in WF core > ----------------------------------------------------------- > > Key: WFCORE-2536 > URL: https://issues.jboss.org/browse/WFCORE-2536 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: James Perkins > Fix For: 3.0.0.Beta12 > > > *org.jboss.as.test.integration.mgmt.access.JmxSensitiveTestCase* > {{cd testsuite/rbac/}} > {{mvn test -Dtest=JmxSensitiveTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:42:13,573 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar )" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.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 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 11:53:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 29 Mar 2017 11:53:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2595) Get rid of the subsystem test framework's use of jboss-metadata-common In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2595: ---------------------------------------- Summary: Get rid of the subsystem test framework's use of jboss-metadata-common Key: WFCORE-2595 URL: https://issues.jboss.org/browse/WFCORE-2595 Project: WildFly Core Issue Type: Task Components: Domain Management, Test Suite Reporter: Brian Stansberry The subsystem test framework's SchemaValidator class requires some expression resolution stuff from jboss-metadata-common, which means we have a test-only dep on that lib in core. Look into using something else for this, e.g. ExpressionResolver.SIMPLE_LENIENT. All it is doing is replacing expressions with defaults with the default value. SchemaValidator is less useful than we originally envisioned anyway, as a lot of the subsystem templates cannot be valid as they include substitution data. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 12:10:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 29 Mar 2017 12:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reassigned WFCORE-2534: ------------------------------------- Assignee: ehsavoie Hugonnet (was: James Perkins) > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 12:10:00 2017 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 29 Mar 2017 12:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386121#comment-13386121 ] James Perkins commented on WFCORE-2534: --------------------------------------- Reassigned to [~ehugonnet] because he said he has this working locally. > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar )" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 12:23:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 29 Mar 2017 12:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8468) NotSerializableException: org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication when using distributed SSO w/Elytron In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro moved JBEAP-9999 to WFLY-8468: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8468 (was: JBEAP-9999) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering Security Web (Undertow) (was: Clustering) (was: Security) (was: Web (Undertow)) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR15) > NotSerializableException: org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication when using distributed SSO w/Elytron > ------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-8468 > URL: https://issues.jboss.org/browse/WFLY-8468 > Project: WildFly > Issue Type: Bug > Components: Clustering, Security, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > Labels: authentication, http, sso, undertow > > Having distributable application backed by Undertow {{application-security-domain}} with Elytron SSO set (for FORM mechanism), successful login attempts results in the following error: > {noformat} > 15:57:34,903 ERROR [org.infinispan.remoting.rpc.RpcManagerImpl] (default task-4) ISPN000073: Unexpected error while replicating: org.infinispan.commons.marshall.NotSerializableException: org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication > Caused by: an exception which occurred: > in object org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication at 46ef57a5 > in object org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue at 46ef57a5 > in object org.wildfly.clustering.web.infinispan.sso.AuthenticationEntry at 417b03e9 > in object org.infinispan.commands.write.PutKeyValueCommand at 9646d052 > in object org.infinispan.commands.tx.PrepareCommand at 50ee6487 > 15:57:34,905 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-4) ISPN000136: Error executing command PrepareCommand, writing keys [AuthenticationKey(ukdiDnE0KJg46OUFshcxq6XIE2xnV9JZRJfpScWx), CoarseSessionsKey(ukdiDnE0KJg46OUFshcxq6XIE2xnV9JZRJfpScWx)]: org.infinispan.commons.marshall.NotSerializableException: org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication > Caused by: an exception which occurred: > in object org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication at 46ef57a5 > in object org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue at 46ef57a5 > in object org.wildfly.clustering.web.infinispan.sso.AuthenticationEntry at 417b03e9 > in object org.infinispan.commands.write.PutKeyValueCommand at 9646d052 > in object org.infinispan.commands.tx.PrepareCommand at 50ee6487 > 15:57:34,905 ERROR [org.infinispan.transaction.impl.TransactionCoordinator] (default task-4) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.commons.marshall.NotSerializableException: org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication > Caused by: an exception which occurred: > in object org.wildfly.clustering.web.undertow.sso.elytron.ElytronAuthentication at 46ef57a5 > in object org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue at 46ef57a5 > in object org.wildfly.clustering.web.infinispan.sso.AuthenticationEntry at 417b03e9 > in object org.infinispan.commands.write.PutKeyValueCommand at 9646d052 > in object org.infinispan.commands.tx.PrepareCommand at 50ee6487 > {noformat} > Priority is set to blocker because it blocks EAP7-596. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 12:55:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 29 Mar 2017 12:55:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1028) AuthenticationException should extend IOException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1028: ---------------------------------- Fix Version/s: 1.1.0.Beta34 > AuthenticationException should extend IOException > ------------------------------------------------- > > Key: ELY-1028 > URL: https://issues.jboss.org/browse/ELY-1028 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta34 > > > Remote authentications use I/O. AuthenticationException pertains solely to remote authentications. Therefore it (like SaslException and many others) should extend IOException, not GeneralSecurityException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 13:03:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Wed, 29 Mar 2017 13:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8439) Unregistering node throws error: MEM: Can't update or insert context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan reopened WFLY-8439: ------------------------------ I reverted the PR following feedback > Unregistering node throws error: MEM: Can't update or insert context > -------------------------------------------------------------------- > > Key: WFLY-8439 > URL: https://issues.jboss.org/browse/WFLY-8439 > Project: WildFly > Issue Type: Bug > Components: mod_cluster, Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Labels: mod_cluster > Fix For: 11.0.0.Beta1 > > > New error message in proxy balancer log > {noformat} > 2017-03-21 15:22:24,957 INFO [io.undertow] (default task-23) UT005047: Unregistering context wildfly-services, from node jboss-eap-7.1-1 > 2017-03-21 15:22:24,962 ERROR [io.undertow] (default task-23) UT005043: Error in processing MCMP commands: Type:MEM, Mess: MEM: Can't update or insert context > 2017-03-21 15:22:28,694 INFO [io.undertow] (default task-29) UT005047: Unregistering context wildfly-services, from node jboss-eap-7.1-2 > 2017-03-21 15:22:28,696 ERROR [io.undertow] (default task-29) UT005043: Error in processing MCMP commands: Type:MEM, Mess: MEM: Can't update or insert context > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 13:55:02 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 13:55:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2596) Upgrade PicketBox from 5.0.0.Beta1 to 5.0.0.Final In-Reply-To: References: Message-ID: Stefan Guilhen created WFCORE-2596: -------------------------------------- Summary: Upgrade PicketBox from 5.0.0.Beta1 to 5.0.0.Final Key: WFCORE-2596 URL: https://issues.jboss.org/browse/WFCORE-2596 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:21:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 14:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-966) Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-966: --------------------------------------- Summary: Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context Key: SECURITY-966 URL: https://issues.jboss.org/browse/SECURITY-966 Project: PicketBox Issue Type: Bug Components: JBossSX, Security-SPI Affects Versions: PicketBox_5_0_0.Beta1 Reporter: Stefan Guilhen Assignee: Stefan Guilhen It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] }, "rolled-back" => true } The exported key manager is announced as org.wildfly.security.key-managers capability. Hence it is expected to work wherever the capability is requested. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:22:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 14:22:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-966) Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen updated SECURITY-966: ------------------------------------ Description: It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: {noformat} { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] }, "rolled-back" => true } {noformat} The exported key manager is announced as org.wildfly.security.key-managers capability. Hence it is expected to work wherever the capability is requested. was: It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] }, "rolled-back" => true } The exported key manager is announced as org.wildfly.security.key-managers capability. Hence it is expected to work wherever the capability is requested. > Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context > ---------------------------------------------------------------------------------------------- > > Key: SECURITY-966 > URL: https://issues.jboss.org/browse/SECURITY-966 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_5_0_0.Beta1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > > It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] > }, > "rolled-back" => true > } > {noformat} > The exported key manager is announced as org.wildfly.security.key-managers capability. Hence it is expected to work wherever the capability is requested. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:23:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 14:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-966) Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen updated SECURITY-966: ------------------------------------ Description: It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: {noformat} { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] }, "rolled-back" => true } {noformat} The exported KeyManager doesn't extend the X509ExtendedKeyManager class. A simple change to SecurityKeyManager should make it compatible with the Elytron ssl contexts. was: It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: {noformat} { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] }, "rolled-back" => true } {noformat} The exported key manager is announced as org.wildfly.security.key-managers capability. Hence it is expected to work wherever the capability is requested. > Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context > ---------------------------------------------------------------------------------------------- > > Key: SECURITY-966 > URL: https://issues.jboss.org/browse/SECURITY-966 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_5_0_0.Beta1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > > It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] > }, > "rolled-back" => true > } > {noformat} > The exported KeyManager doesn't extend the X509ExtendedKeyManager class. A simple change to SecurityKeyManager should make it compatible with the Elytron ssl contexts. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:25:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 14:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-966) Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen updated SECURITY-966: ------------------------------------ Fix Version/s: PicketBox_5_0_0.Final > Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context > ---------------------------------------------------------------------------------------------- > > Key: SECURITY-966 > URL: https://issues.jboss.org/browse/SECURITY-966 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_5_0_0.Beta1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_5_0_0.Final > > > It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] > }, > "rolled-back" => true > } > {noformat} > The exported KeyManager doesn't extend the X509ExtendedKeyManager class. A simple change to SecurityKeyManager should make it compatible with the Elytron ssl contexts. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:28:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 14:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-966) Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen resolved SECURITY-966. ------------------------------------- Resolution: Done SecurityKeyManager has been changed to extend X509ExtendedKeyManager, thus becoming compatible with the Elytron SSL contexts. > Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context > ---------------------------------------------------------------------------------------------- > > Key: SECURITY-966 > URL: https://issues.jboss.org/browse/SECURITY-966 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_5_0_0.Beta1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_5_0_0.Final > > > It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] > }, > "rolled-back" => true > } > {noformat} > The exported KeyManager doesn't extend the X509ExtendedKeyManager class. A simple change to SecurityKeyManager should make it compatible with the Elytron ssl contexts. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:28:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 14:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-966) Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen closed SECURITY-966. ----------------------------------- > Key manager exported from legacy JSSE security domain does not work Elytron server-ssl-context > ---------------------------------------------------------------------------------------------- > > Key: SECURITY-966 > URL: https://issues.jboss.org/browse/SECURITY-966 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_5_0_0.Beta1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_5_0_0.Final > > > It is not possible to use a key manager exported from legacy security domain (i.e. elytron-key-manager) in Elytron server-ssl-context. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssc" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssc: WFLYELY00019: No 'X509ExtendedKeyManager' found in injected value."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.ssc"] > }, > "rolled-back" => true > } > {noformat} > The exported KeyManager doesn't extend the X509ExtendedKeyManager class. A simple change to SecurityKeyManager should make it compatible with the Elytron ssl contexts. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:41:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 14:41:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-81) Baseline #3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-81: ---------------------------------- Attachment: March28_0200_raw.zip > Baseline #3 > ----------- > > Key: HAWKULARQE-81 > URL: https://issues.jboss.org/browse/HAWKULARQE-81 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: March28_0200_raw.zip > > > * Run pyme on master to eliminate vpn slowness > * Fix query start-end window > * Update pyme endpoint to increase metrics to 30 (currently 2) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 14:42:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 14:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-81) Baseline #3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386204#comment-13386204 ] viet nguyen commented on HAWKULARQE-81: --------------------------------------- After set query window to a fix range (March 28 02:00, -30 minutes) the metrics tallies are consistent between 4 runs. [^March28_0200_raw.zip] > Baseline #3 > ----------- > > Key: HAWKULARQE-81 > URL: https://issues.jboss.org/browse/HAWKULARQE-81 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: March28_0200_raw.zip > > > * Run pyme on master to eliminate vpn slowness > * Fix query start-end window > * Update pyme endpoint to increase metrics to 30 (currently 2) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 15:06:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 15:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-967) Release PicketBox 5.0.0.Final In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-967: --------------------------------------- Summary: Release PicketBox 5.0.0.Final Key: SECURITY-967 URL: https://issues.jboss.org/browse/SECURITY-967 Project: PicketBox Issue Type: Task Components: JBossSX, Security-SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 15:10:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 15:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-967) Release PicketBox 5.0.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen closed SECURITY-967. ----------------------------------- Resolution: Done PicketBox 5.0.0.Final has been released and is available on Nexus > Release PicketBox 5.0.0.Final > ----------------------------- > > Key: SECURITY-967 > URL: https://issues.jboss.org/browse/SECURITY-967 > Project: PicketBox > Issue Type: Task > Components: JBossSX, Security-SPI > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 15:24:00 2017 From: issues at jboss.org (viet nguyen (JIRA)) Date: Wed, 29 Mar 2017 15:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-81) Baseline #3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viet nguyen updated HAWKULARQE-81: ---------------------------------- Description: * Run pyme on master to eliminate vpn slowness * Fix query start-end window * Update pyme endpoint to increase metrics to 30 (currently 2) * insert metrics tallies into a separate Hawkular Metrics instance and user Grafana as a visual tool was: * Run pyme on master to eliminate vpn slowness * Fix query start-end window * Update pyme endpoint to increase metrics to 30 (currently 2) > Baseline #3 > ----------- > > Key: HAWKULARQE-81 > URL: https://issues.jboss.org/browse/HAWKULARQE-81 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: March28_0200_raw.zip > > > * Run pyme on master to eliminate vpn slowness > * Fix query start-end window > * Update pyme endpoint to increase metrics to 30 (currently 2) > * insert metrics tallies into a separate Hawkular Metrics instance and user Grafana as a visual tool -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 15:31:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 15:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2596) Upgrade PicketBox from 5.0.0.Beta1 to 5.0.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen updated WFCORE-2596: ----------------------------------- Summary: Upgrade PicketBox from 5.0.0.Beta1 to 5.0.1.Final (was: Upgrade PicketBox from 5.0.0.Beta1 to 5.0.0.Final) > Upgrade PicketBox from 5.0.0.Beta1 to 5.0.1.Final > ------------------------------------------------- > > Key: WFCORE-2596 > URL: https://issues.jboss.org/browse/WFCORE-2596 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 15:32:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 15:32:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-968) Release PicketBox 5.0.1.Final In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-968: --------------------------------------- Summary: Release PicketBox 5.0.1.Final Key: SECURITY-968 URL: https://issues.jboss.org/browse/SECURITY-968 Project: PicketBox Issue Type: Task Components: JBossSX, Security-SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 15:45:00 2017 From: issues at jboss.org (Erick de Oliveira Leal (JIRA)) Date: Wed, 29 Mar 2017 15:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8469) upgrade to JSF 2.3 In-Reply-To: References: Message-ID: Erick de Oliveira Leal created WFLY-8469: -------------------------------------------- Summary: upgrade to JSF 2.3 Key: WFLY-8469 URL: https://issues.jboss.org/browse/WFLY-8469 Project: WildFly Issue Type: Component Upgrade Components: JSF Affects Versions: 11.0.0.Alpha1 Reporter: Erick de Oliveira Leal Assignee: Farah Juma Priority: Minor JSF 2.3 is out http://arjan-tijms.omnifaces.org/2017/03/jsf-23-released.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 16:03:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 16:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-968) Release PicketBox 5.0.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen closed SECURITY-968. ----------------------------------- Resolution: Done PicketBox 5.0.1.Final has been released and is available on Nexus > Release PicketBox 5.0.1.Final > ----------------------------- > > Key: SECURITY-968 > URL: https://issues.jboss.org/browse/SECURITY-968 > Project: PicketBox > Issue Type: Task > Components: JBossSX, Security-SPI > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:03:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 29 Mar 2017 17:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8470) [GSS](7.1.0) Upgrade mod_cluster to 1.3.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar moved JBEAP-10001 to WFLY-8470: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8470 (was: JBEAP-10001) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: mod_cluster (was: Build System) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR8) > [GSS](7.1.0) Upgrade mod_cluster to 1.3.6.Final > ----------------------------------------------- > > Key: WFLY-8470 > URL: https://issues.jboss.org/browse/WFLY-8470 > Project: WildFly > Issue Type: Component Upgrade > Components: mod_cluster > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:04:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Wed, 29 Mar 2017 17:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8470) Upgrade mod_cluster to 1.3.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-8470: --------------------------------- Summary: Upgrade mod_cluster to 1.3.6.Final (was: [GSS](7.1.0) Upgrade mod_cluster to 1.3.6.Final) > Upgrade mod_cluster to 1.3.6.Final > ---------------------------------- > > Key: WFLY-8470 > URL: https://issues.jboss.org/browse/WFLY-8470 > Project: WildFly > Issue Type: Component Upgrade > Components: mod_cluster > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:25:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 29 Mar 2017 17:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2597) PathManager not available at ServiceName generated by its capability In-Reply-To: References: Message-ID: Paul Ferraro created WFCORE-2597: ------------------------------------ Summary: PathManager not available at ServiceName generated by its capability Key: WFCORE-2597 URL: https://issues.jboss.org/browse/WFCORE-2597 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Beta11 Reporter: Paul Ferraro Assignee: Paul Ferraro Install Service using ServiceName from capability, where the legacy ServiceName is an alias. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:26:00 2017 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 29 Mar 2017 17:26:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-970) Fix potential NPE in ApplicationPolicyParser In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-970: --------------------------------------- Summary: Fix potential NPE in ApplicationPolicyParser Key: SECURITY-970 URL: https://issues.jboss.org/browse/SECURITY-970 Project: PicketBox Issue Type: Enhancement Components: JBossSX Affects Versions: PicketBox_5_0_0.Alpha1 Reporter: Kylin Soong Assignee: Kylin Soong Fix For: PicketBox_5_0_0.Beta1 Use LdapExtLoginModule in j2se with condifg: {code} com.sun.jndi.ldap.LdapCtxFactory ldap://10.66.218.46:389 simple cn=Manager,dc=example,dc=com redhat ou=Customers,dc=example,dc=com (uid={0}) ou=Roles,dc=example,dc=com (uniqueMember={1}) cn {code} authentication parse section code [1] line 123: {code} AuthenticationInfo authInfo = new AuthenticationInfo(); {code} which this cause null set as AuthenticationInfo name, then cause 'jboss.security.security_domain=null' as options be passed to LdapExtLoginModule, this null value finally cause NPE in LdapExtLoginModule line around 840 {code} Entry entry = (Entry) iter.next(); env.put(entry.getKey(), entry.getValue()); {code} [1] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/config/parser/ApplicationPolicyParser.java [2] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/auth/spi/LdapExtLoginModule.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:27:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 29 Mar 2017 17:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2597) PathManager not available at ServiceName indicated by its capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFCORE-2597: --------------------------------- Summary: PathManager not available at ServiceName indicated by its capability (was: PathManager not available at ServiceName generated by its capability) > PathManager not available at ServiceName indicated by its capability > -------------------------------------------------------------------- > > Key: WFCORE-2597 > URL: https://issues.jboss.org/browse/WFCORE-2597 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Install Service using ServiceName from capability, where the legacy ServiceName is an alias. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:39:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 29 Mar 2017 17:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386262#comment-13386262 ] Stuart Douglas commented on WFLY-8466: -------------------------------------- Can you test with the latest Undertow (1.4.11.Final) and see if this resolves it? > Socket leak when setting HTTP Content-Length and client not reading entire response > ----------------------------------------------------------------------------------- > > Key: WFLY-8466 > URL: https://issues.jboss.org/browse/WFLY-8466 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: CentOS 6.7 > Reporter: Johannes Ritter > Assignee: Stuart Douglas > Labels: leak, socket > Attachments: socket_leak.tar.gz > > > Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set. > The leaked sockets can be determined by "lsof -p | grep identify". The relevant sockets are listed with "Can't identify protocol". > The leak occurs if the client connection is closed (on the client side) before the server could send the complete response. > It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click. > *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 17:49:00 2017 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 29 Mar 2017 17:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2598) PathManager capability registration not available to resources In-Reply-To: References: Message-ID: Paul Ferraro created WFCORE-2598: ------------------------------------ Summary: PathManager capability registration not available to resources Key: WFCORE-2598 URL: https://issues.jboss.org/browse/WFCORE-2598 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Beta11 Reporter: Paul Ferraro Assignee: Brian Stansberry When attempting to add a requirement on the PathManager capability to a capability registered with some resource, e.g. {noformat} RuntimeCapability MY_CAPABILITY = RuntimeCapability.Builder.of("foo").addRequirements("org.wildfly.management.path-manager").build(); {noformat} I get the following error during boot: 16:30:55,229 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=infinispan/cache-container=web/distributed-cache=dist/store=file' are not available: org.wildfly.management.path-manager; There are no known registration points which can provide this capability. It seems like this capability registration isn't available to subsystem resources. Here's the real world use case: https://github.com/pferraro/wildfly/commit/d5a00ecb6975137e40848b45abfc668c513e849f See org.jboss.as.clustering.infinispan.subsystem.FileStoreResourceDefinition -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 29 20:37:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 29 Mar 2017 20:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2595) Get rid of the subsystem test framework's use of jboss-metadata-common In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386284#comment-13386284 ] Brian Stansberry commented on WFCORE-2595: ------------------------------------------ What the jboss-metadata stuff brings that ExpressionResolver doesn't is resolution against a set of passed in properties. > Get rid of the subsystem test framework's use of jboss-metadata-common > ---------------------------------------------------------------------- > > Key: WFCORE-2595 > URL: https://issues.jboss.org/browse/WFCORE-2595 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > > The subsystem test framework's SchemaValidator class requires some expression resolution stuff from jboss-metadata-common, which means we have a test-only dep on that lib in core. Look into using something else for this, e.g. ExpressionResolver.SIMPLE_LENIENT. All it is doing is replacing expressions with defaults with the default value. > SchemaValidator is less useful than we originally envisioned anyway, as a lot of the subsystem templates cannot be valid as they include substitution data. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 01:02:00 2017 From: issues at jboss.org (Martin Choma (JIRA)) Date: Thu, 30 Mar 2017 01:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8471) Elytron, *-authentication-factory protocol attribute should be case insensitive In-Reply-To: References: Message-ID: Martin Choma created WFLY-8471: ---------------------------------- Summary: Elytron, *-authentication-factory protocol attribute should be case insensitive Key: WFLY-8471 URL: https://issues.jboss.org/browse/WFLY-8471 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker When I use "HTTP" in protocol attribute instead of "http", I get 403 instead of succesfull access. According to http://www.rfc-base.org/txt/rfc-1738.txt Scheme names consist of a sequence of characters. The lower case ?? letters "a"--"z", digits, and the characters plus ("+"), period ?? ("."), and hyphen ("-") are allowed. For resiliency, programs ?? interpreting URLs should treat upper case letters as equivalent to ?? lower case in scheme names (e.g., allow "HTTP" as well as "http"). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 01:13:00 2017 From: issues at jboss.org (Manjunath S Paramesan (JIRA)) Date: Thu, 30 Mar 2017 01:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386300#comment-13386300 ] Manjunath S Paramesan commented on DROOLS-1471: ----------------------------------------------- This is not resolved in drools 6.5. We can reproduce this in drools 6.5. > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 01:21:00 2017 From: issues at jboss.org (Manjunath S Paramesan (JIRA)) Date: Thu, 30 Mar 2017 01:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjunath S Paramesan updated DROOLS-1471: ------------------------------------------ Affects Version/s: 6.5.0.Final > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final, 6.5.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 02:19:00 2017 From: issues at jboss.org (Johannes Ritter (JIRA)) Date: Thu, 30 Mar 2017 02:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386316#comment-13386316 ] Johannes Ritter commented on WFLY-8466: --------------------------------------- Thank you for the hint. After some first tests with Undertow 1.4.11 the issue seems to be fixed. I downloaded Undertow 1.4.11 from [here|https://github.com/undertow-io/undertow/releases] and upgraded the following 3 modules: * modules/system/layers/base/io/undertow/core/main/undertow-core-1.4.11.Final.jar * modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.4.11.Final.jar * modules/system/layers/base/io/undertow/websocket/main/undertow-websockets-jsr-1.4.11.Final.jar I couldn't find a replacement for "modules/system/layers/base/io/undertow/js/main/undertow-js-1.0.2.Final.jar". Since we have a serious issue on one of our customer's system regarding the socket leak I would like to upgrade Undertow on the customer system. It is save to only upgrade the 3 listed modules? > Socket leak when setting HTTP Content-Length and client not reading entire response > ----------------------------------------------------------------------------------- > > Key: WFLY-8466 > URL: https://issues.jboss.org/browse/WFLY-8466 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: CentOS 6.7 > Reporter: Johannes Ritter > Assignee: Stuart Douglas > Labels: leak, socket > Attachments: socket_leak.tar.gz > > > Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set. > The leaked sockets can be determined by "lsof -p | grep identify". The relevant sockets are listed with "Can't identify protocol". > The leak occurs if the client connection is closed (on the client side) before the server could send the complete response. > It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click. > *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 02:19:00 2017 From: issues at jboss.org (Vladimir Dosoudil (JIRA)) Date: Thu, 30 Mar 2017 02:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8472) Upgrade picketlink to 2.5.5.SP7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Dosoudil moved JBEAP-10004 to WFLY-8472: ------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8472 (was: JBEAP-10004) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Build System) > Upgrade picketlink to 2.5.5.SP7 > ------------------------------- > > Key: WFLY-8472 > URL: https://issues.jboss.org/browse/WFLY-8472 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Reporter: Vladimir Dosoudil > Assignee: Petr Saka? > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 02:20:00 2017 From: issues at jboss.org (Vladimir Dosoudil (JIRA)) Date: Thu, 30 Mar 2017 02:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8472) Upgrade picketlink to 2.5.5.SP7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Dosoudil reassigned WFLY-8472: --------------------------------------- Assignee: Vladimir Dosoudil (was: Petr Saka?) > Upgrade picketlink to 2.5.5.SP7 > ------------------------------- > > Key: WFLY-8472 > URL: https://issues.jboss.org/browse/WFLY-8472 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Reporter: Vladimir Dosoudil > Assignee: Vladimir Dosoudil > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 03:05:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 30 Mar 2017 03:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386329#comment-13386329 ] Stuart Douglas commented on WFLY-8466: -------------------------------------- Yes, those three are all that are required > Socket leak when setting HTTP Content-Length and client not reading entire response > ----------------------------------------------------------------------------------- > > Key: WFLY-8466 > URL: https://issues.jboss.org/browse/WFLY-8466 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: CentOS 6.7 > Reporter: Johannes Ritter > Assignee: Stuart Douglas > Labels: leak, socket > Attachments: socket_leak.tar.gz > > > Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set. > The leaked sockets can be determined by "lsof -p | grep identify". The relevant sockets are listed with "Can't identify protocol". > The leak occurs if the client connection is closed (on the client side) before the server could send the complete response. > It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click. > *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 03:10:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 30 Mar 2017 03:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1499) When concurrently get prototype ksession bean, it could be repeated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-1499. --------------------------------- Fix Version/s: 7.0.0.CR1 Resolution: Done Fixed by https://github.com/kiegroup/droolsjbpm-integration/commit/c4ff59a9d0ba0463ccce48bbb44c20f539671c77 > When concurrently get prototype ksession bean, it could be repeated > ------------------------------------------------------------------- > > Key: DROOLS-1499 > URL: https://issues.jboss.org/browse/DROOLS-1499 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 6.5.0.Final > Reporter: ?? ? > Assignee: Mario Fusco > Fix For: 7.0.0.CR1 > > > when currently get ksession bean , there could be repeated ksessions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 04:21:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 30 Mar 2017 04:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1043) CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1043: --------------------------------- Summary: CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore Key: ELY-1043 URL: https://issues.jboss.org/browse/ELY-1043 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Priority: Blocker CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore. It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 04:21:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 30 Mar 2017 04:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1044) CS tool has to support bulk conversion of vaults to credential stores. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1044: --------------------------------- Summary: CS tool has to support bulk conversion of vaults to credential stores. Key: ELY-1044 URL: https://issues.jboss.org/browse/ELY-1044 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse Priority: Blocker CS tool has to support bulk conversion of vaults to credential stores. It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 04:23:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 30 Mar 2017 04:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1044) CS tool has to support bulk conversion of vaults to credential stores. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1044: ------------------------------ Component/s: Command-Line Tool > CS tool has to support bulk conversion of vaults to credential stores. > ---------------------------------------------------------------------- > > Key: ELY-1044 > URL: https://issues.jboss.org/browse/ELY-1044 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > CS tool has to support bulk conversion of vaults to credential stores. > It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 04:23:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Thu, 30 Mar 2017 04:23:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1043) CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1043: ------------------------------ Component/s: Command-Line Tool > CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore > ---------------------------------------------------------------------------------------------- > > Key: ELY-1043 > URL: https://issues.jboss.org/browse/ELY-1043 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Reporter: Hynek ?v?bek > Assignee: Darran Lofthouse > Priority: Blocker > > CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore. > It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 05:02:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Thu, 30 Mar 2017 05:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1502) Incorrect "local" namespace resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Mortari updated DROOLS-1502: ----------------------------------- Description: The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: [ EDIT : there was a wrong DMN model example ] and it's throwing two distinct types of NPEs.. (follows) was: The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: {code:xml} feel:string "a","b","c" MyInput - "Decision taken" {code} and it's throwing two distinct types of NPEs.. (follows) > Incorrect "local" namespace resolution > -------------------------------------- > > Key: DROOLS-1502 > URL: https://issues.jboss.org/browse/DROOLS-1502 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: > [ EDIT : there was a wrong DMN model example ] > and it's throwing two distinct types of NPEs.. (follows) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 05:05:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Thu, 30 Mar 2017 05:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1502) Incorrect "local" namespace resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Mortari updated DROOLS-1502: ----------------------------------- Comment: was deleted (was: First problem is {{DMNCompilerImpl.resolveTypeRef()}} which was not considering local namespace for the QName as resolved by the unmarshalling {code:java} 16:28:24.122 [main] ERROR o.k.d.core.compiler.DMNCompilerImpl.compile:78 - Error compiling model from source. java.lang.NullPointerException: null at org.kie.dmn.core.compiler.DMNCompilerImpl.resolveTypeRef(DMNCompilerImpl.java:398) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.buildTypeDef(DMNCompilerImpl.java:290) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.processItemDefinitions(DMNCompilerImpl.java:100) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:90) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:75) [classes/:na] at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:64) [classes/:na] at org.kie.dmn.core.assembler.DMNAssemblerService.addResource(DMNAssemblerService.java:55) [classes/:na] {code} ) > Incorrect "local" namespace resolution > -------------------------------------- > > Key: DROOLS-1502 > URL: https://issues.jboss.org/browse/DROOLS-1502 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: > [ EDIT : there was a wrong DMN model example ] > and it's throwing two distinct types of NPEs.. (follows) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 05:06:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Thu, 30 Mar 2017 05:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1502) Incorrect "local" namespace resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386403#comment-13386403 ] Matteo Mortari commented on DROOLS-1502: ---------------------------------------- The "second problem" can be actually demonstrated with a valid DMN example file e.g.: {code:xml} feel:string "a","b","c" MyInput - "Decision taken" {code} > Incorrect "local" namespace resolution > -------------------------------------- > > Key: DROOLS-1502 > URL: https://issues.jboss.org/browse/DROOLS-1502 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > The following example DMN model similar to an already existing in the code base is modified for "local" xmlns namespace definition: > [ EDIT : there was a wrong DMN model example ] > and it's throwing two distinct types of NPEs.. (follows) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 05:42:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 30 Mar 2017 05:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2599) CLI complex object completer issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise reassigned WFCORE-2599: -------------------------------------------- Assignee: Jean-Francois Denise > CLI complex object completer issues > ----------------------------------- > > Key: WFCORE-2599 > URL: https://issues.jboss.org/browse/WFCORE-2599 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > When a Complex Object property is ruled by filesystem or capability metadata, when the value to complete is already complete (full file name, full capability name), the completer miss behave. > In this case, the completer doesn't propose the "," or "}" character that allows to continue Object completion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 05:42:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 30 Mar 2017 05:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2599) CLI complex object completer issues In-Reply-To: References: Message-ID: Jean-Francois Denise created WFCORE-2599: -------------------------------------------- Summary: CLI complex object completer issues Key: WFCORE-2599 URL: https://issues.jboss.org/browse/WFCORE-2599 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise When a Complex Object property is ruled by filesystem or capability metadata, when the value to complete is already complete (full file name, full capability name), the completer miss behave. In this case, the completer doesn't propose the "," or "}" character that allows to continue Object completion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 06:01:01 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Thu, 30 Mar 2017 06:01:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2599) CLI complex object completer issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Francois Denise updated WFCORE-2599: ----------------------------------------- Priority: Minor (was: Major) > CLI complex object completer issues > ----------------------------------- > > Key: WFCORE-2599 > URL: https://issues.jboss.org/browse/WFCORE-2599 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Minor > > When a Complex Object property is ruled by filesystem or capability metadata, when the value to complete is already complete (full file name, full capability name), the completer miss behave. > In this case, the completer doesn't propose the "," or "}" character that allows to continue Object completion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 06:04:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 06:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8473) Introduce capabilites in undertow subsystem In-Reply-To: References: Message-ID: Tomaz Cerar created WFLY-8473: --------------------------------- Summary: Introduce capabilites in undertow subsystem Key: WFLY-8473 URL: https://issues.jboss.org/browse/WFLY-8473 Project: WildFly Issue Type: Enhancement Reporter: Tomaz Cerar Assignee: Tomaz Cerar Majority of undertow subsystem should move to capabilites. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 06:06:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 06:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2471) Elytron kerberos-security-factory debug attribute type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2471: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Elytron kerberos-security-factory debug attribute type > ------------------------------------------------------ > > Key: WFCORE-2471 > URL: https://issues.jboss.org/browse/WFCORE-2471 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 3.0.0.Beta12 > > > Currently kerberos-security-factory debug attribute is in management model defined as STRING type, but could be BOOLEAN. > {code} > "kerberos-security-factory" => { > "description" => "A security factory for obtaining a GSSCredential for use during authentication.", > "model-description" => {"*" => { > "description" => "A security factory for obtaining a GSSCredential for use during authentication.", > "capabilities" => [{ > "name" => "org.wildfly.security.security-factory.credential", > "dynamic" => true > }], > "attributes" => { > "debug" => { > "type" => STRING, > "description" => "Should the JAAS step of obtaining the credential have debug logging enabled.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > In XSD it is properly configured as boolean > {code:xml} > > > > Should the JAAS step of obtaining the credential have debug logging enabled. > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 06:51:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 06:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1034) Updated HTTP Authentication Mechanism Status Code Handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1034: ---------------------------------- Summary: Updated HTTP Authentication Mechanism Status Code Handling (was: Allow HTTP authentication mechanisms to use Status 500 / Internal Server Error) > Updated HTTP Authentication Mechanism Status Code Handling > ---------------------------------------------------------- > > Key: ELY-1034 > URL: https://issues.jboss.org/browse/ELY-1034 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Some mechanisms are unable to operate correctly due to internal errors / configuration issues. > When this happens they should be able to provide a responder which sets the status code to 500. However if other mechanisms can respond they should and the 500 be dropped. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 06:58:01 2017 From: issues at jboss.org (Ondrej Lukas (JIRA)) Date: Thu, 30 Mar 2017 06:58:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8125) Programatically set Elytron AuthenticationContext does not work in application server modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Lukas closed WFLY-8125. ------------------------------ Resolution: Rejected After deeper look at the issue described in this Jira we find out an issue in our test. Closing this issue as not a bug. > Programatically set Elytron AuthenticationContext does not work in application server modules > --------------------------------------------------------------------------------------------- > > Key: WFLY-8125 > URL: https://issues.jboss.org/browse/WFLY-8125 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: David Lloyd > Priority: Blocker > Attachments: module-without-wildfly-config-xml-dep.war, module-without-wildfly-config-xml.jar > > > In case when code inside of any module in aplication server executes management operation through programatically configured AuthenticationContext then it is not work correctly. > According to server log it seems that for some reason it at the first authenticate correctly through programatically configured AuthenticationContext, but then it try to reauthenticate through AuthenticationContext obtained from application server (if default-authentication-context is set then it is used; otherwise reauthenticate fails completetly). > The same type of behavior occurs also when {{wildfly.config.url}} property is used. > Request blocker flag because this issue breaks RFE. > Server log (when default-authentication-context is set, see Steps to Reproduce): > {code} > 2017-02-15 13:43:30,584 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990] > 2017-02-15 13:43:30,585 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990] > 2017-02-15 13:43:30,596 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback > 2017-02-15 13:43:30,597 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback > 2017-02-15 13:43:30,598 TRACE [org.wildfly.security] (management I/O-2) Handling AvailableRealmsCallback: realms = [ManagementRealm] > 2017-02-15 13:43:30,607 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ManagementRealm] > 2017-02-15 13:43:30,608 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = user2 > 2017-02-15 13:43:30,610 TRACE [org.wildfly.security] (management task-10) Principal assigning: [user2], pre-realm rewritten: [user2], realm name: [ManagementRealm], post realm rewritten: [user2], realm rewritten: [user2] > 2017-02-15 13:43:30,614 TRACE [org.wildfly.security] (management task-10) Handling CredentialCallback: obtained successfully > 2017-02-15 13:43:30,615 TRACE [org.wildfly.security] (management task-10) Role mapping: principal [user2] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing principal user2. > 2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing against the following attributes: [groups] => [] > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Permission mapping: identity [user2] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Authorization succeed > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) RunAs authorization succeed - the same identity > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Handling AuthorizeCallback: authenticationID = user2 authorizationID = user2 authorized = true > 2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling AuthenticationCompleteCallback: succeed > 2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity at 9b7d11 > 2017-02-15 13:43:30,640 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990] > 2017-02-15 13:43:30,641 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990] > 2017-02-15 13:43:30,652 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback > 2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback > 2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling AvailableRealmsCallback: realms = [ManagementRealm] > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling RealmCallback: selected = [ManagementRealm] > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling NameCallback: authenticationName = user1 > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [ManagementRealm], post realm rewritten: [user1], realm rewritten: [user1] > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling CredentialCallback: obtained successfully > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Role mapping: principal [user1] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing principal user1. > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing against the following attributes: [groups] => [] > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Permission mapping: identity [user1] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorization succeed > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) RunAs authorization succeed - the same identity > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthorizeCallback: authenticationID = user1 authorizationID = user1 authorized = true > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthenticationCompleteCallback: succeed > 2017-02-15 13:43:30,658 TRACE [org.wildfly.security] (management task-6) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity at 53367941 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 06:59:01 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 30 Mar 2017 06:59:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2600) CLITestUtil should set connectionTimeout value to something more than 5 secs which is the default now In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky moved JBEAP-10019 to WFCORE-2600: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2600 (was: JBEAP-10019) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: 3.0.0.Beta11 (was: 7.1.0.DR10) (was: 7.1.0.DR11) (was: 7.1.0.DR13) > CLITestUtil should set connectionTimeout value to something more than 5 secs which is the default now > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-2600 > URL: https://issues.jboss.org/browse/WFCORE-2600 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta11 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > *Description of problem:* > ObjectStoreTypeTestCase fails intermittently on IPv6. This test is *not* from wf-core. > *How reproducible:* > * 5% > * this issue is more common on pure IPv6 machines with IBM JDK > *Actual results:* > Maven logs: > {noformat} > 12:52:47 Running org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > 12:55:18 Tests run: 5, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 151.197 sec <<< FAILURE! - in org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > 12:55:18 testJdbcObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 38.363 sec <<< FAILURE! > 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > 12:55:18 at org.junit.Assert.fail(Assert.java:88) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) > 12:55:18 > 12:55:18 testJournalObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 29.533 sec <<< FAILURE! > 12:55:18 org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> > 12:55:18 at org.junit.Assert.assertEquals(Assert.java:115) > 12:55:18 at org.junit.Assert.assertEquals(Assert.java:144) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) > 12:55:18 > 12:55:18 testUseJdbcStoreWithoutDatasource(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 27.734 sec <<< FAILURE! > 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > 12:55:18 (\"subsystem\" => \"datasources\"), > 12:55:18 (\"data-source\" => \"ObjectStoreTestDS\") > 12:55:18 ]"}} > 12:55:18 at org.junit.Assert.fail(Assert.java:88) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) > {noformat} > Standard output: > {noformat} > 12:52:47,276 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:52:47,545 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:52:47,560 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > 12:52:48,082 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta12-redhat-1 > 12:52:48,164 INFO [org.xnio] (main) XNIO version 3.4.3.Final-redhat-1 > 12:52:48,287 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > 12:52:49,068 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m12:52:51,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:52:53,468 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:52:54,015 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:52:54,668 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:52:59,007 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:52:59,191 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 10) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:00,425 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:00,462 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:00,507 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:00,832 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:00,925 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:53:00,931 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:01,147 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:53:01,159 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:53:01,209 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:01,309 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:01,317 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[33m12:53:01,454 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:01,512 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:01,545 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:01,733 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:01,801 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:53:02,025 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:02,027 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:02,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:02,479 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:02,833 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:02,834 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:03,020 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:03,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:03,091 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:03,447 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:03,696 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:03,723 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:03,772 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:04,334 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:04,335 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:04,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:05,306 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:05,331 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:05,575 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:05,581 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:05,883 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:53:08,210 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 19241ms - Started 351 of 670 services (471 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:08,215 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:14,504 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:53:15,001 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > &#27;[0m12:53:15,570 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m12:53:16,773 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:17,319 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > &#27;[0m12:53:17,429 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:17,430 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:17,433 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:17,439 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:17,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:17,511 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:17,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:17,514 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:17,515 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:17,426 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:17,572 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:17,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:17,623 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:17,672 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:17,870 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:18,039 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 696ms > &#27;[0m&#27;[0m12:53:18,042 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:53:19,098 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:19,281 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:20,041 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:20,160 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:20,219 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:20,196 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:20,274 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:20,282 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:20,306 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:20,314 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:20,329 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:20,344 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[33m12:53:20,348 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:20,359 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:53:20,579 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:20,606 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:20,608 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:20,613 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:20,642 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:20,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:20,646 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:20,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:20,759 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:20,769 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:20,773 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:20,768 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:20,843 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:22,444 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:22,447 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:22,448 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:22,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:22,479 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[33m12:53:23,156 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getWrappedConnection(BaseWrapperManagedConnection.java:1203) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getConnection(BaseWrapperManagedConnection.java:462) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.openConnection(XAResourceRecoveryImpl.java:438) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:199) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) > ... 10 more > &#27;[0m&#27;[33m12:53:23,161 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:563) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) > at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) > at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.jca.core.recovery.DefaultRecoveryPlugin.close(DefaultRecoveryPlugin.java:107) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.closeConnection(XAResourceRecoveryImpl.java:469) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:212) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) > ... 17 more > &#27;[0m&#27;[0m12:53:23,749 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 4,5,management-handler-thread] > &#27;[0m&#27;[0m12:53:24,045 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:24,078 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:53:24,099 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 6053ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:24,326 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:53:24,382 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:53:24,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:24,572 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:24,574 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:24,765 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:24,828 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:24,857 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:24,860 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:24,965 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:24,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:24,972 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:24,973 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:24,978 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:25,073 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 492ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore* > StackTrace: > {noformat} > org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) > {noformat} > Standard output: > {noformat} > 12:53:25,500 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:53:25,523 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:53:25,547 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > &#27;[0m12:53:28,442 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:53:31,091 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:53:31,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:53:32,467 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:53:37,670 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:37,965 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:40,066 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:40,279 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:40,364 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[33m12:53:40,699 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:40,791 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:40,824 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:40,920 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:40,941 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:53:41,430 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:53:41,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:41,489 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:53:41,508 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:53:41,678 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:41,691 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:41,701 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:41,905 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:41,912 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:53:41,909 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:42,064 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:42,159 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:42,659 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:43,061 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:43,209 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:43,362 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:43,363 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:44,187 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:44,206 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:44,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:44,295 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:44,304 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:46,834 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:46,835 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:46,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:46,989 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:47,003 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:47,005 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:47,364 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:48,055 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:53:50,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:50,640 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:50,641 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 24187ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:50,642 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:51,263 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:53:51,444 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "jdbc" > } > 12:53:51,506 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "jdbc" > } > 12:53:52,356 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:52,835 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,259 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,715 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,775 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:53:53,803 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:53:53,873 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:53:54,090 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:54,152 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:54,154 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:54,346 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:54,414 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:54,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:54,539 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:54,601 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:54,627 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:54,536 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:54,630 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:54,633 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:54,665 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:54,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:54,738 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 533ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"datasources\"), > (\"data-source\" => \"ObjectStoreTestDS\") > ]"}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) > {noformat} > Standard output: > {noformat} > 12:53:54,968 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:53:54,976 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:53:54,996 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > &#27;[0m12:53:57,625 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:54:00,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:54:00,857 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:54:01,702 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:54:06,509 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:54:06,719 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 22) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:54:08,905 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:54:09,017 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:09,056 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:09,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:54:09,652 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:54:09,658 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:54:09,699 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[33m12:54:09,791 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:54:09,859 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:54:09,918 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:54:10,021 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:54:10,083 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:54:10,150 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:54:10,161 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:54:10,371 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:54:10,372 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:54:10,449 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:54:10,938 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:54:11,007 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:54:11,381 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:54:12,044 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:54:12,045 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:54:12,049 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:54:12,572 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:54:13,204 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:54:13,207 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:54:13,232 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:54:13,239 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:54:13,246 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:13,290 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:54:13,573 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:54:13,608 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:54:13,614 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:54:14,914 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:54:15,209 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:54:15,212 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:54:15,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:54:16,087 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:54:19,471 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:54:19,472 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 23779ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m12:54:20,014 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:54:20,148 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:54:20,584 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:54:21,270 INFO [org.jboss.as.cli.CommandContext] (main) operation-requires-reload: true > process-state: reload-required > 12:54:21,342 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:54:21,433 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:54:21,498 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:54:21,698 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:54:21,775 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:54:21,777 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:54:21,976 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:54:22,019 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:54:22,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:54:22,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:54:22,166 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:54:22,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:54:22,173 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:54:22,180 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:54:22,246 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:54:22,247 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:54:22,323 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:54:22,428 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 611ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line '/subsystem=transactions/log-store=log-store:read-attribute(name=type)': org.jboss.as.cli.CommandFormatException: No connection to the controller. > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.readObjectStoreType(ObjectStoreTypeTestCase.java:265) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:275) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:271) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore(ObjectStoreTypeTestCase.java:89) > {noformat} > Standard output: > {noformat} > 12:03:49,027 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:03:49,033 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:03:49,036 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:196, -Dnode1=2620:52:0:105f::ffff:197, -Dmcast=ff0e:52:0:105f::ffff:199, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-12, -c=standalone-ha.xml] > &#27;[0m12:03:50,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1 > &#27;[0m&#27;[0m12:03:53,752 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1 > &#27;[0m&#27;[0m12:03:54,152 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting > &#27;[0m&#27;[0m12:03:54,774 INFO [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:03:59,746 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:03:59,994 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1 > &#27;[0m&#27;[0m12:03:59,996 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 6) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 > &#27;[0m&#27;[0m12:04:00,083 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 28) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:01,997 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:04:02,081 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:04:02,112 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:04:02,472 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:04:02,526 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[33m12:04:02,569 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:04:02,942 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 49) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:04:02,994 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:04:03,030 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:04:03,072 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:04:03,084 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:04:03,094 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:04:03,134 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:04:03,602 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:04:03,688 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) > &#27;[0m&#27;[0m12:04:04,386 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:04:04,555 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:04,556 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:04:04,628 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:04:04,804 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:04:04,871 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:04:04,899 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:05,546 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:04:06,048 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:06,116 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:04:06,279 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 > &#27;[0m&#27;[0m12:04:06,302 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:06,494 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 > &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:06,813 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:07,765 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:04:07,962 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:04:07,965 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:04:08,245 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:08,821 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) > &#27;[0m&#27;[0m12:04:11,110 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:04:11,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management > &#27;[0m&#27;[0m12:04:11,148 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 > &#27;[0m&#27;[0m12:04:11,149 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 21534ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) > &#27;[0m12:04:11,579 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:04:11,637 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:04:12,297 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > &#27;[0m12:04:12,438 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:12,439 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:12,459 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:12,466 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:04:12,473 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:04:12,474 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:12,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:04:12,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:12,491 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:04:12,550 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:12,676 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:04:12,678 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:12,688 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:04:12,936 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:12,984 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 670ms > &#27;[0m&#27;[0m12:04:12,988 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting > &#27;[0m&#27;[0m12:04:14,141 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:14,319 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 14) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 > &#27;[0m&#27;[0m12:04:14,346 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:14,928 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:04:15,085 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:04:15,088 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[33m12:04:15,097 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:04:15,123 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:04:15,155 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:04:15,161 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:04:15,176 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:04:15,211 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:04:15,237 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) > &#27;[0m&#27;[0m12:04:15,241 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:04:15,306 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:04:15,345 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:04:15,347 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:04:15,268 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:04:15,674 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:15,675 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:04:15,701 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:15,702 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:04:15,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:15,826 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 > &#27;[0m&#27;[0m12:04:15,831 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 > &#27;[0m&#27;[0m12:04:15,896 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:04:15,929 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:16,002 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:16,006 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:15,937 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:16,815 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:04:16,852 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:04:16,854 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:04:16,892 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:16,895 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) > &#27;[0m12:04:18,708 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:04:18,760 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management > &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 > &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 5768ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:04:18,767 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:04:18,906 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:04:18,964 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:04:19,116 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:19,139 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:19,140 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:19,236 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:04:19,244 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:04:19,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:04:19,369 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:19,370 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:04:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:19,421 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:19,480 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:04:19,481 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:19,483 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:04:19,562 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 375ms > &#27;[0m > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 07:03:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 30 Mar 2017 07:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2600) CLITestUtil should set connectionTimeout value to something more than 5 secs which is the default now In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky updated WFCORE-2600: ---------------------------------- Description: CLITestUtil creates a command context without setting connectionTimeout. The default value of connectionTimeout is 5 seconds then. This value seems to be too low under some circumstances, see *Description of problem:* ObjectStoreTypeTestCase fails intermittently on IPv6 due to a too low connectionTimeout set by CLITestUtil. This test is *not* from wf-core. Actually, the CLITestUtil does not set connectionTimeout *How reproducible:* * 5% * this issue is more common on pure IPv6 machines with IBM JDK *Actual results:* Maven logs: {noformat} 12:52:47 Running org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase 12:55:18 Tests run: 5, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 151.197 sec <<< FAILURE! - in org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase 12:55:18 testJdbcObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 38.363 sec <<< FAILURE! 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). 12:55:18 at org.junit.Assert.fail(Assert.java:88) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) 12:55:18 12:55:18 testJournalObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 29.533 sec <<< FAILURE! 12:55:18 org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> 12:55:18 at org.junit.Assert.assertEquals(Assert.java:115) 12:55:18 at org.junit.Assert.assertEquals(Assert.java:144) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) 12:55:18 12:55:18 testUseJdbcStoreWithoutDatasource(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 27.734 sec <<< FAILURE! 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ 12:55:18 (\"subsystem\" => \"datasources\"), 12:55:18 (\"data-source\" => \"ObjectStoreTestDS\") 12:55:18 ]"}} 12:55:18 at org.junit.Assert.fail(Assert.java:88) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) {noformat} Standard output: {noformat} 12:52:47,276 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:52:47,545 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:52:47,560 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] 12:52:48,082 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta12-redhat-1 12:52:48,164 INFO [org.xnio] (main) XNIO version 3.4.3.Final-redhat-1 12:52:48,287 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 12:52:49,068 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m12:52:51,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:52:53,468 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:52:54,015 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:52:54,668 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:52:59,007 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:52:59,191 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 10) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:00,425 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:00,462 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:00,507 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:00,832 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:00,925 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:53:00,931 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:01,147 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:53:01,159 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:53:01,209 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:01,309 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:01,317 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[33m12:53:01,454 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:01,512 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:01,545 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:01,733 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:01,801 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:53:02,025 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:02,027 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:02,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:02,479 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:02,833 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:02,834 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:03,020 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:03,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:03,091 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:03,447 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:03,696 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:03,723 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:03,772 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:04,334 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:04,335 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:04,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:05,306 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:05,331 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:05,575 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:05,581 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:05,883 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:53:08,210 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 19241ms - Started 351 of 670 services (471 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:08,215 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:14,504 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:53:15,001 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } &#27;[0m12:53:15,570 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m12:53:16,773 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:17,319 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } &#27;[0m12:53:17,429 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:17,430 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:17,433 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:17,439 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:17,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:17,511 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:17,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:17,514 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:17,515 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:17,426 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:17,572 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:17,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:17,623 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:17,672 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:17,870 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:18,039 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 696ms &#27;[0m&#27;[0m12:53:18,042 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:53:19,098 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:19,281 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:20,041 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:20,160 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:20,219 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:20,196 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:20,274 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:20,282 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:20,306 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:20,314 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:20,329 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:20,344 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[33m12:53:20,348 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:20,359 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:53:20,579 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:20,606 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:20,608 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:20,613 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:20,642 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:20,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:20,646 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:20,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:20,759 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:20,769 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:20,773 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:20,768 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:20,843 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:22,444 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:22,447 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:22,448 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:22,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:22,479 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[33m12:53:23,156 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getWrappedConnection(BaseWrapperManagedConnection.java:1203) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getConnection(BaseWrapperManagedConnection.java:462) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.openConnection(XAResourceRecoveryImpl.java:438) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:199) at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:348) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) ... 10 more &#27;[0m&#27;[33m12:53:23,161 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:563) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.jca.core.recovery.DefaultRecoveryPlugin.close(DefaultRecoveryPlugin.java:107) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.closeConnection(XAResourceRecoveryImpl.java:469) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:212) at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:348) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) ... 17 more &#27;[0m&#27;[0m12:53:23,749 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 4,5,management-handler-thread] &#27;[0m&#27;[0m12:53:24,045 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:24,078 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:53:24,099 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 6053ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:24,326 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:53:24,382 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:53:24,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:24,572 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:24,574 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:24,765 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:24,828 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:24,857 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:24,860 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:24,965 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:24,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:24,972 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:24,973 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:24,978 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:25,073 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 492ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore* StackTrace: {noformat} org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) {noformat} Standard output: {noformat} 12:53:25,500 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:53:25,523 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:53:25,547 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] &#27;[0m12:53:28,442 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:53:31,091 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:53:31,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:53:32,467 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:53:37,670 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:37,965 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:40,066 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:40,279 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:40,364 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[33m12:53:40,699 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:40,791 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:40,824 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:40,920 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:40,941 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:53:41,430 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:53:41,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:41,489 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:53:41,508 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:53:41,678 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:41,691 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:41,701 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:41,905 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:41,912 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:53:41,909 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:42,064 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:42,159 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:42,659 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:43,061 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:43,209 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:43,362 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:43,363 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:44,187 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:44,206 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:44,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:44,295 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:44,304 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:46,834 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:46,835 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:46,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:46,989 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:47,003 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:47,005 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:47,364 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:48,055 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:53:50,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:50,640 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:50,641 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 24187ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:50,642 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:51,263 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:53:51,444 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "jdbc" } 12:53:51,506 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "jdbc" } 12:53:52,356 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:52,835 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,259 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,715 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,775 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:53:53,803 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:53:53,873 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:53:54,090 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:54,152 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:54,154 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:54,346 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:54,414 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:54,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:54,539 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:54,601 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:54,627 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:54,536 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:54,630 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:54,633 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:54,665 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:54,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:54,738 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 533ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ (\"subsystem\" => \"datasources\"), (\"data-source\" => \"ObjectStoreTestDS\") ]"}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) {noformat} Standard output: {noformat} 12:53:54,968 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:53:54,976 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:53:54,996 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] &#27;[0m12:53:57,625 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:54:00,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:54:00,857 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:54:01,702 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:54:06,509 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:54:06,719 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 22) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:54:08,905 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:54:09,017 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:09,056 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:09,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:54:09,652 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:54:09,658 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:54:09,699 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[33m12:54:09,791 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:54:09,859 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:54:09,918 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:54:10,021 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:54:10,083 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:54:10,150 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:54:10,161 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:54:10,371 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:54:10,372 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:54:10,449 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:54:10,938 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:54:11,007 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:54:11,381 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:54:12,044 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:54:12,045 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:54:12,049 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:54:12,572 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:54:13,204 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:54:13,207 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:54:13,232 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:54:13,239 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:54:13,246 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:13,290 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:54:13,573 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:54:13,608 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:54:13,614 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:54:14,914 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:54:15,209 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:54:15,212 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:54:15,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:54:16,087 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:54:19,471 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:54:19,472 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 23779ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m12:54:20,014 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:54:20,148 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:54:20,584 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:54:21,270 INFO [org.jboss.as.cli.CommandContext] (main) operation-requires-reload: true process-state: reload-required 12:54:21,342 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:54:21,433 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:54:21,498 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:54:21,698 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:54:21,775 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:54:21,777 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:54:21,976 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:54:22,019 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:54:22,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:54:22,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:54:22,166 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:54:22,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:54:22,173 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:54:22,180 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:54:22,246 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:54:22,247 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:54:22,323 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:54:22,428 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 611ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line '/subsystem=transactions/log-store=log-store:read-attribute(name=type)': org.jboss.as.cli.CommandFormatException: No connection to the controller. at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.readObjectStoreType(ObjectStoreTypeTestCase.java:265) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:275) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:271) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore(ObjectStoreTypeTestCase.java:89) {noformat} Standard output: {noformat} 12:03:49,027 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:03:49,033 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:03:49,036 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:196, -Dnode1=2620:52:0:105f::ffff:197, -Dmcast=ff0e:52:0:105f::ffff:199, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-12, -c=standalone-ha.xml] &#27;[0m12:03:50,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1 &#27;[0m&#27;[0m12:03:53,752 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1 &#27;[0m&#27;[0m12:03:54,152 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting &#27;[0m&#27;[0m12:03:54,774 INFO [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:03:59,746 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:03:59,994 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1 &#27;[0m&#27;[0m12:03:59,996 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 6) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 &#27;[0m&#27;[0m12:04:00,083 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 28) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:01,997 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:04:02,081 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:04:02,112 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:04:02,472 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:04:02,526 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[33m12:04:02,569 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:04:02,942 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 49) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:04:02,994 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:04:03,030 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:04:03,072 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:04:03,084 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:04:03,094 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:04:03,134 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:04:03,602 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:04:03,688 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) &#27;[0m&#27;[0m12:04:04,386 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:04:04,555 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:04,556 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:04:04,628 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:04:04,804 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:04:04,871 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:04:04,899 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:05,546 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:04:06,048 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:06,116 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:04:06,279 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 &#27;[0m&#27;[0m12:04:06,302 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:06,494 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:06,813 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:07,765 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:04:07,962 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:04:07,965 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:04:08,245 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:08,821 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) &#27;[0m&#27;[0m12:04:11,110 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:04:11,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management &#27;[0m&#27;[0m12:04:11,148 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 &#27;[0m&#27;[0m12:04:11,149 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 21534ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) &#27;[0m12:04:11,579 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:04:11,637 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:04:12,297 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } &#27;[0m12:04:12,438 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:12,439 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:12,459 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:12,466 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:04:12,473 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:04:12,474 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:12,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:04:12,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:12,491 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:04:12,550 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:12,676 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:04:12,678 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:12,688 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:04:12,936 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:12,984 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 670ms &#27;[0m&#27;[0m12:04:12,988 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting &#27;[0m&#27;[0m12:04:14,141 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:14,319 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 14) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 &#27;[0m&#27;[0m12:04:14,346 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:14,928 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:04:15,085 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:04:15,088 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[33m12:04:15,097 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:04:15,123 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:04:15,155 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:04:15,161 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:04:15,176 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:04:15,211 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:04:15,237 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) &#27;[0m&#27;[0m12:04:15,241 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:04:15,306 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:04:15,345 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:04:15,347 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:04:15,268 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:04:15,674 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:15,675 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:04:15,701 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:15,702 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:04:15,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:15,826 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 &#27;[0m&#27;[0m12:04:15,831 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 &#27;[0m&#27;[0m12:04:15,896 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:04:15,929 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:16,002 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:16,006 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:15,937 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:16,815 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:04:16,852 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:04:16,854 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:04:16,892 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:16,895 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) &#27;[0m12:04:18,708 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:04:18,760 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 5768ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:04:18,767 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:04:18,906 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:04:18,964 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:04:19,116 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:19,139 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:19,140 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:19,236 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:04:19,244 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:04:19,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:04:19,369 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:19,370 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:04:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:19,421 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:19,480 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:04:19,481 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:19,483 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:04:19,562 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 375ms &#27;[0m {noformat} *Expected results:* No errors was: *Description of problem:* ObjectStoreTypeTestCase fails intermittently on IPv6. This test is *not* from wf-core. *How reproducible:* * 5% * this issue is more common on pure IPv6 machines with IBM JDK *Actual results:* Maven logs: {noformat} 12:52:47 Running org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase 12:55:18 Tests run: 5, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 151.197 sec <<< FAILURE! - in org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase 12:55:18 testJdbcObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 38.363 sec <<< FAILURE! 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). 12:55:18 at org.junit.Assert.fail(Assert.java:88) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) 12:55:18 12:55:18 testJournalObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 29.533 sec <<< FAILURE! 12:55:18 org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> 12:55:18 at org.junit.Assert.assertEquals(Assert.java:115) 12:55:18 at org.junit.Assert.assertEquals(Assert.java:144) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) 12:55:18 12:55:18 testUseJdbcStoreWithoutDatasource(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 27.734 sec <<< FAILURE! 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ 12:55:18 (\"subsystem\" => \"datasources\"), 12:55:18 (\"data-source\" => \"ObjectStoreTestDS\") 12:55:18 ]"}} 12:55:18 at org.junit.Assert.fail(Assert.java:88) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) {noformat} Standard output: {noformat} 12:52:47,276 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:52:47,545 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:52:47,560 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] 12:52:48,082 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta12-redhat-1 12:52:48,164 INFO [org.xnio] (main) XNIO version 3.4.3.Final-redhat-1 12:52:48,287 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 12:52:49,068 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m12:52:51,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:52:53,468 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:52:54,015 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:52:54,668 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:52:59,007 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:52:59,191 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 10) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:00,425 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:00,462 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:00,507 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:00,832 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:00,925 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:53:00,931 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:01,147 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:53:01,159 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:53:01,209 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:01,309 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:01,317 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[33m12:53:01,454 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:01,512 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:01,545 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:01,733 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:01,801 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:53:02,025 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:02,027 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:02,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:02,479 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:02,833 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:02,834 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:03,020 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:03,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:03,091 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:03,447 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:03,696 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:03,723 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:03,772 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:04,334 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:04,335 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:04,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:05,306 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:05,331 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:05,575 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:05,581 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:05,883 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:53:08,210 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 19241ms - Started 351 of 670 services (471 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:08,215 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:14,504 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:53:15,001 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } &#27;[0m12:53:15,570 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m12:53:16,773 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:17,319 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } &#27;[0m12:53:17,429 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:17,430 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:17,433 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:17,439 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:17,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:17,511 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:17,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:17,514 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:17,515 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:17,426 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:17,572 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:17,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:17,623 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:17,672 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:17,870 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:18,039 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 696ms &#27;[0m&#27;[0m12:53:18,042 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:53:19,098 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:19,281 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:20,041 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:20,160 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:20,219 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:20,196 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:20,274 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:20,282 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:20,306 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:20,314 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:20,329 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:20,344 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[33m12:53:20,348 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:20,359 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:53:20,579 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:20,606 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:20,608 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:20,613 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:20,642 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:20,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:20,646 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:20,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:20,759 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:20,769 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:20,773 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:20,768 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:20,843 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:22,444 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:22,447 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:22,448 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:22,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:22,479 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[33m12:53:23,156 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getWrappedConnection(BaseWrapperManagedConnection.java:1203) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getConnection(BaseWrapperManagedConnection.java:462) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.openConnection(XAResourceRecoveryImpl.java:438) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:199) at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:348) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) ... 10 more &#27;[0m&#27;[33m12:53:23,161 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:563) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.jca.core.recovery.DefaultRecoveryPlugin.close(DefaultRecoveryPlugin.java:107) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.closeConnection(XAResourceRecoveryImpl.java:469) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:212) at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:348) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) ... 17 more &#27;[0m&#27;[0m12:53:23,749 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 4,5,management-handler-thread] &#27;[0m&#27;[0m12:53:24,045 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:24,078 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:53:24,099 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 6053ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:24,326 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:53:24,382 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:53:24,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:24,572 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:24,574 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:24,765 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:24,828 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:24,857 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:24,860 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:24,965 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:24,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:24,972 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:24,973 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:24,978 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:25,073 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 492ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore* StackTrace: {noformat} org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) {noformat} Standard output: {noformat} 12:53:25,500 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:53:25,523 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:53:25,547 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] &#27;[0m12:53:28,442 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:53:31,091 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:53:31,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:53:32,467 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:53:37,670 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:37,965 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:40,066 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:40,279 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:40,364 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[33m12:53:40,699 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:40,791 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:40,824 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:40,920 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:40,941 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:53:41,430 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:53:41,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:41,489 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:53:41,508 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:53:41,678 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:41,691 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:41,701 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:41,905 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:41,912 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:53:41,909 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:42,064 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:42,159 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:42,659 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:43,061 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:43,209 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:43,362 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:43,363 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:44,187 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:44,206 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:44,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:44,295 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:44,304 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:46,834 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:46,835 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:46,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:46,989 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:47,003 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:47,005 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:47,364 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:48,055 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:53:50,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:50,640 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:50,641 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 24187ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:50,642 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:51,263 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:53:51,444 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "jdbc" } 12:53:51,506 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "jdbc" } 12:53:52,356 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:52,835 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,259 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,715 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,775 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:53:53,803 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:53:53,873 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:53:54,090 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:54,152 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:54,154 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:54,346 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:54,414 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:54,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:54,539 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:54,601 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:54,627 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:54,536 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:54,630 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:54,633 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:54,665 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:54,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:54,738 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 533ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ (\"subsystem\" => \"datasources\"), (\"data-source\" => \"ObjectStoreTestDS\") ]"}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) {noformat} Standard output: {noformat} 12:53:54,968 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:53:54,976 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:53:54,996 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] &#27;[0m12:53:57,625 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:54:00,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:54:00,857 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:54:01,702 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:54:06,509 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:54:06,719 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 22) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:54:08,905 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:54:09,017 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:09,056 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:09,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:54:09,652 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:54:09,658 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:54:09,699 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[33m12:54:09,791 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:54:09,859 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:54:09,918 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:54:10,021 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:54:10,083 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:54:10,150 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:54:10,161 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:54:10,371 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:54:10,372 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:54:10,449 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:54:10,938 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:54:11,007 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:54:11,381 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:54:12,044 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:54:12,045 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:54:12,049 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:54:12,572 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:54:13,204 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:54:13,207 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:54:13,232 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:54:13,239 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:54:13,246 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:13,290 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:54:13,573 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:54:13,608 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:54:13,614 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:54:14,914 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:54:15,209 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:54:15,212 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:54:15,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:54:16,087 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:54:19,471 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:54:19,472 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 23779ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m12:54:20,014 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:54:20,148 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:54:20,584 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:54:21,270 INFO [org.jboss.as.cli.CommandContext] (main) operation-requires-reload: true process-state: reload-required 12:54:21,342 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:54:21,433 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:54:21,498 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:54:21,698 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:54:21,775 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:54:21,777 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:54:21,976 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:54:22,019 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:54:22,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:54:22,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:54:22,166 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:54:22,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:54:22,173 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:54:22,180 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:54:22,246 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:54:22,247 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:54:22,323 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:54:22,428 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 611ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line '/subsystem=transactions/log-store=log-store:read-attribute(name=type)': org.jboss.as.cli.CommandFormatException: No connection to the controller. at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.readObjectStoreType(ObjectStoreTypeTestCase.java:265) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:275) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:271) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore(ObjectStoreTypeTestCase.java:89) {noformat} Standard output: {noformat} 12:03:49,027 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:03:49,033 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:03:49,036 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:196, -Dnode1=2620:52:0:105f::ffff:197, -Dmcast=ff0e:52:0:105f::ffff:199, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-12, -c=standalone-ha.xml] &#27;[0m12:03:50,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1 &#27;[0m&#27;[0m12:03:53,752 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1 &#27;[0m&#27;[0m12:03:54,152 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting &#27;[0m&#27;[0m12:03:54,774 INFO [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:03:59,746 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:03:59,994 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1 &#27;[0m&#27;[0m12:03:59,996 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 6) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 &#27;[0m&#27;[0m12:04:00,083 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 28) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:01,997 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:04:02,081 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:04:02,112 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:04:02,472 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:04:02,526 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[33m12:04:02,569 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:04:02,942 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 49) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:04:02,994 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:04:03,030 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:04:03,072 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:04:03,084 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:04:03,094 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:04:03,134 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:04:03,602 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:04:03,688 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) &#27;[0m&#27;[0m12:04:04,386 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:04:04,555 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:04,556 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:04:04,628 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:04:04,804 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:04:04,871 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:04:04,899 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:05,546 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:04:06,048 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:06,116 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:04:06,279 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 &#27;[0m&#27;[0m12:04:06,302 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:06,494 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:06,813 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:07,765 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:04:07,962 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:04:07,965 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:04:08,245 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:08,821 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) &#27;[0m&#27;[0m12:04:11,110 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:04:11,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management &#27;[0m&#27;[0m12:04:11,148 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 &#27;[0m&#27;[0m12:04:11,149 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 21534ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) &#27;[0m12:04:11,579 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:04:11,637 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:04:12,297 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } &#27;[0m12:04:12,438 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:12,439 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:12,459 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:12,466 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:04:12,473 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:04:12,474 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:12,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:04:12,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:12,491 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:04:12,550 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:12,676 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:04:12,678 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:12,688 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:04:12,936 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:12,984 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 670ms &#27;[0m&#27;[0m12:04:12,988 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting &#27;[0m&#27;[0m12:04:14,141 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:14,319 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 14) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 &#27;[0m&#27;[0m12:04:14,346 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:14,928 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:04:15,085 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:04:15,088 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[33m12:04:15,097 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:04:15,123 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:04:15,155 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:04:15,161 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:04:15,176 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:04:15,211 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:04:15,237 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) &#27;[0m&#27;[0m12:04:15,241 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:04:15,306 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:04:15,345 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:04:15,347 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:04:15,268 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:04:15,674 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:15,675 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:04:15,701 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:15,702 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:04:15,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:15,826 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 &#27;[0m&#27;[0m12:04:15,831 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 &#27;[0m&#27;[0m12:04:15,896 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:04:15,929 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:16,002 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:16,006 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:15,937 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:16,815 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:04:16,852 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:04:16,854 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:04:16,892 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:16,895 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) &#27;[0m12:04:18,708 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:04:18,760 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 5768ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:04:18,767 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:04:18,906 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:04:18,964 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:04:19,116 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:19,139 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:19,140 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:19,236 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:04:19,244 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:04:19,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:04:19,369 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:19,370 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:04:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:19,421 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:19,480 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:04:19,481 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:19,483 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:04:19,562 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 375ms &#27;[0m {noformat} *Expected results:* No errors > CLITestUtil should set connectionTimeout value to something more than 5 secs which is the default now > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-2600 > URL: https://issues.jboss.org/browse/WFCORE-2600 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta11 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > CLITestUtil creates a command context without setting connectionTimeout. The default value of connectionTimeout is 5 seconds then. This value seems to be too low under some circumstances, see > *Description of problem:* > ObjectStoreTypeTestCase fails intermittently on IPv6 due to a too low connectionTimeout set by CLITestUtil. > This test is *not* from wf-core. > Actually, the CLITestUtil does not set connectionTimeout > *How reproducible:* > * 5% > * this issue is more common on pure IPv6 machines with IBM JDK > *Actual results:* > Maven logs: > {noformat} > 12:52:47 Running org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > 12:55:18 Tests run: 5, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 151.197 sec <<< FAILURE! - in org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > 12:55:18 testJdbcObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 38.363 sec <<< FAILURE! > 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > 12:55:18 at org.junit.Assert.fail(Assert.java:88) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) > 12:55:18 > 12:55:18 testJournalObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 29.533 sec <<< FAILURE! > 12:55:18 org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> > 12:55:18 at org.junit.Assert.assertEquals(Assert.java:115) > 12:55:18 at org.junit.Assert.assertEquals(Assert.java:144) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) > 12:55:18 > 12:55:18 testUseJdbcStoreWithoutDatasource(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 27.734 sec <<< FAILURE! > 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > 12:55:18 (\"subsystem\" => \"datasources\"), > 12:55:18 (\"data-source\" => \"ObjectStoreTestDS\") > 12:55:18 ]"}} > 12:55:18 at org.junit.Assert.fail(Assert.java:88) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) > {noformat} > Standard output: > {noformat} > 12:52:47,276 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:52:47,545 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:52:47,560 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > 12:52:48,082 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta12-redhat-1 > 12:52:48,164 INFO [org.xnio] (main) XNIO version 3.4.3.Final-redhat-1 > 12:52:48,287 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > 12:52:49,068 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m12:52:51,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:52:53,468 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:52:54,015 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:52:54,668 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:52:59,007 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:52:59,191 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 10) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:00,425 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:00,462 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:00,507 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:00,832 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:00,925 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:53:00,931 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:01,147 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:53:01,159 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:53:01,209 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:01,309 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:01,317 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[33m12:53:01,454 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:01,512 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:01,545 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:01,733 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:01,801 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:53:02,025 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:02,027 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:02,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:02,479 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:02,833 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:02,834 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:03,020 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:03,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:03,091 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:03,447 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:03,696 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:03,723 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:03,772 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:04,334 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:04,335 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:04,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:05,306 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:05,331 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:05,575 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:05,581 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:05,883 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:53:08,210 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 19241ms - Started 351 of 670 services (471 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:08,215 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:14,504 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:53:15,001 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > &#27;[0m12:53:15,570 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m12:53:16,773 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:17,319 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > &#27;[0m12:53:17,429 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:17,430 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:17,433 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:17,439 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:17,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:17,511 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:17,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:17,514 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:17,515 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:17,426 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:17,572 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:17,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:17,623 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:17,672 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:17,870 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:18,039 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 696ms > &#27;[0m&#27;[0m12:53:18,042 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:53:19,098 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:19,281 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:20,041 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:20,160 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:20,219 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:20,196 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:20,274 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:20,282 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:20,306 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:20,314 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:20,329 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:20,344 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[33m12:53:20,348 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:20,359 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:53:20,579 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:20,606 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:20,608 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:20,613 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:20,642 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:20,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:20,646 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:20,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:20,759 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:20,769 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:20,773 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:20,768 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:20,843 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:22,444 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:22,447 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:22,448 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:22,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:22,479 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[33m12:53:23,156 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getWrappedConnection(BaseWrapperManagedConnection.java:1203) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getConnection(BaseWrapperManagedConnection.java:462) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.openConnection(XAResourceRecoveryImpl.java:438) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:199) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) > ... 10 more > &#27;[0m&#27;[33m12:53:23,161 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:563) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) > at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) > at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.jca.core.recovery.DefaultRecoveryPlugin.close(DefaultRecoveryPlugin.java:107) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.closeConnection(XAResourceRecoveryImpl.java:469) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:212) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) > ... 17 more > &#27;[0m&#27;[0m12:53:23,749 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 4,5,management-handler-thread] > &#27;[0m&#27;[0m12:53:24,045 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:24,078 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:53:24,099 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 6053ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:24,326 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:53:24,382 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:53:24,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:24,572 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:24,574 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:24,765 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:24,828 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:24,857 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:24,860 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:24,965 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:24,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:24,972 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:24,973 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:24,978 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:25,073 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 492ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore* > StackTrace: > {noformat} > org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) > {noformat} > Standard output: > {noformat} > 12:53:25,500 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:53:25,523 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:53:25,547 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > &#27;[0m12:53:28,442 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:53:31,091 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:53:31,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:53:32,467 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:53:37,670 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:37,965 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:40,066 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:40,279 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:40,364 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[33m12:53:40,699 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:40,791 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:40,824 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:40,920 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:40,941 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:53:41,430 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:53:41,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:41,489 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:53:41,508 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:53:41,678 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:41,691 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:41,701 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:41,905 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:41,912 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:53:41,909 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:42,064 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:42,159 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:42,659 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:43,061 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:43,209 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:43,362 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:43,363 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:44,187 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:44,206 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:44,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:44,295 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:44,304 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:46,834 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:46,835 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:46,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:46,989 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:47,003 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:47,005 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:47,364 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:48,055 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:53:50,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:50,640 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:50,641 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 24187ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:50,642 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:51,263 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:53:51,444 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "jdbc" > } > 12:53:51,506 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "jdbc" > } > 12:53:52,356 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:52,835 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,259 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,715 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,775 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:53:53,803 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:53:53,873 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:53:54,090 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:54,152 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:54,154 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:54,346 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:54,414 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:54,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:54,539 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:54,601 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:54,627 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:54,536 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:54,630 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:54,633 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:54,665 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:54,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:54,738 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 533ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"datasources\"), > (\"data-source\" => \"ObjectStoreTestDS\") > ]"}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) > {noformat} > Standard output: > {noformat} > 12:53:54,968 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:53:54,976 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:53:54,996 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > &#27;[0m12:53:57,625 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:54:00,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:54:00,857 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:54:01,702 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:54:06,509 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:54:06,719 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 22) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:54:08,905 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:54:09,017 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:09,056 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:09,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:54:09,652 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:54:09,658 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:54:09,699 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[33m12:54:09,791 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:54:09,859 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:54:09,918 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:54:10,021 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:54:10,083 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:54:10,150 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:54:10,161 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:54:10,371 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:54:10,372 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:54:10,449 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:54:10,938 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:54:11,007 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:54:11,381 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:54:12,044 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:54:12,045 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:54:12,049 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:54:12,572 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:54:13,204 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:54:13,207 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:54:13,232 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:54:13,239 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:54:13,246 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:13,290 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:54:13,573 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:54:13,608 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:54:13,614 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:54:14,914 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:54:15,209 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:54:15,212 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:54:15,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:54:16,087 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:54:19,471 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:54:19,472 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 23779ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m12:54:20,014 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:54:20,148 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:54:20,584 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:54:21,270 INFO [org.jboss.as.cli.CommandContext] (main) operation-requires-reload: true > process-state: reload-required > 12:54:21,342 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:54:21,433 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:54:21,498 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:54:21,698 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:54:21,775 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:54:21,777 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:54:21,976 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:54:22,019 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:54:22,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:54:22,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:54:22,166 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:54:22,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:54:22,173 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:54:22,180 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:54:22,246 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:54:22,247 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:54:22,323 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:54:22,428 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 611ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line '/subsystem=transactions/log-store=log-store:read-attribute(name=type)': org.jboss.as.cli.CommandFormatException: No connection to the controller. > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.readObjectStoreType(ObjectStoreTypeTestCase.java:265) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:275) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:271) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore(ObjectStoreTypeTestCase.java:89) > {noformat} > Standard output: > {noformat} > 12:03:49,027 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:03:49,033 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:03:49,036 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:196, -Dnode1=2620:52:0:105f::ffff:197, -Dmcast=ff0e:52:0:105f::ffff:199, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-12, -c=standalone-ha.xml] > &#27;[0m12:03:50,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1 > &#27;[0m&#27;[0m12:03:53,752 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1 > &#27;[0m&#27;[0m12:03:54,152 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting > &#27;[0m&#27;[0m12:03:54,774 INFO [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:03:59,746 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:03:59,994 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1 > &#27;[0m&#27;[0m12:03:59,996 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 6) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 > &#27;[0m&#27;[0m12:04:00,083 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 28) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:01,997 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:04:02,081 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:04:02,112 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:04:02,472 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:04:02,526 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[33m12:04:02,569 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:04:02,942 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 49) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:04:02,994 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:04:03,030 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:04:03,072 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:04:03,084 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:04:03,094 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:04:03,134 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:04:03,602 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:04:03,688 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) > &#27;[0m&#27;[0m12:04:04,386 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:04:04,555 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:04,556 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:04:04,628 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:04:04,804 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:04:04,871 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:04:04,899 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:05,546 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:04:06,048 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:06,116 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:04:06,279 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 > &#27;[0m&#27;[0m12:04:06,302 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:06,494 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 > &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:06,813 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:07,765 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:04:07,962 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:04:07,965 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:04:08,245 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:08,821 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) > &#27;[0m&#27;[0m12:04:11,110 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:04:11,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management > &#27;[0m&#27;[0m12:04:11,148 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 > &#27;[0m&#27;[0m12:04:11,149 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 21534ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) > &#27;[0m12:04:11,579 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:04:11,637 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:04:12,297 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > &#27;[0m12:04:12,438 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:12,439 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:12,459 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:12,466 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:04:12,473 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:04:12,474 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:12,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:04:12,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:12,491 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:04:12,550 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:12,676 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:04:12,678 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:12,688 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:04:12,936 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:12,984 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 670ms > &#27;[0m&#27;[0m12:04:12,988 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting > &#27;[0m&#27;[0m12:04:14,141 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:14,319 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 14) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 > &#27;[0m&#27;[0m12:04:14,346 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:14,928 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:04:15,085 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:04:15,088 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[33m12:04:15,097 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:04:15,123 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:04:15,155 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:04:15,161 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:04:15,176 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:04:15,211 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:04:15,237 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) > &#27;[0m&#27;[0m12:04:15,241 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:04:15,306 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:04:15,345 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:04:15,347 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:04:15,268 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:04:15,674 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:15,675 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:04:15,701 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:15,702 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:04:15,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:15,826 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 > &#27;[0m&#27;[0m12:04:15,831 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 > &#27;[0m&#27;[0m12:04:15,896 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:04:15,929 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:16,002 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:16,006 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:15,937 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:16,815 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:04:16,852 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:04:16,854 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:04:16,892 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:16,895 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) > &#27;[0m12:04:18,708 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:04:18,760 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management > &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 > &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 5768ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:04:18,767 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:04:18,906 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:04:18,964 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:04:19,116 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:19,139 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:19,140 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:19,236 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:04:19,244 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:04:19,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:04:19,369 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:19,370 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:04:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:19,421 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:19,480 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:04:19,481 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:19,483 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:04:19,562 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 375ms > &#27;[0m > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 07:03:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 07:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1034) Updated HTTP Authentication Mechanism Status Code Handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1034: ---------------------------------- Description: Update the HTTP status code handling within HTTP authentication to cover the following scenarios: - # If authentication is required and no mechanisms are available report status 500. # If a mechanism fails by throwing an exception and no other mechanisms are able to challenge report status 500. # If a mechanism fails but other mechanisms can still challenge use the challenge from the available mechanisms. # If mechanisms were available but none authenticated and none able to challenge report status 403. was: Some mechanisms are unable to operate correctly due to internal errors / configuration issues. When this happens they should be able to provide a responder which sets the status code to 500. However if other mechanisms can respond they should and the 500 be dropped. > Updated HTTP Authentication Mechanism Status Code Handling > ---------------------------------------------------------- > > Key: ELY-1034 > URL: https://issues.jboss.org/browse/ELY-1034 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > > Update the HTTP status code handling within HTTP authentication to cover the following scenarios: - > # If authentication is required and no mechanisms are available report status 500. > # If a mechanism fails by throwing an exception and no other mechanisms are able to challenge report status 500. > # If a mechanism fails but other mechanisms can still challenge use the challenge from the available mechanisms. > # If mechanisms were available but none authenticated and none able to challenge report status 403. > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 07:08:13 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Thu, 30 Mar 2017 07:08:13 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2600) CLITestUtil should set connectionTimeout value to something more than 5 secs which is the default now In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky updated WFCORE-2600: ---------------------------------- Description: {{CLITestUtil}} creates a command context without setting any {{connectionTimeout}} for it. The default value of the {{connectionTimeout}} is 5 seconds. This value seems to be too low under some circumstances, see JBEAP-8244. {{CLITestUtil}} at line 79 (see \[1\]) should use a different factory method to create the {{CommandContext}} and should provide a decent value for {{connectionTimeout}} too. \[1\] https://github.com/wildfly/wildfly-core/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/management/util/CLITestUtil.java#L79 was: CLITestUtil creates a command context without setting connectionTimeout. The default value of connectionTimeout is 5 seconds then. This value seems to be too low under some circumstances, see *Description of problem:* ObjectStoreTypeTestCase fails intermittently on IPv6 due to a too low connectionTimeout set by CLITestUtil. This test is *not* from wf-core. Actually, the CLITestUtil does not set connectionTimeout *How reproducible:* * 5% * this issue is more common on pure IPv6 machines with IBM JDK *Actual results:* Maven logs: {noformat} 12:52:47 Running org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase 12:55:18 Tests run: 5, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 151.197 sec <<< FAILURE! - in org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase 12:55:18 testJdbcObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 38.363 sec <<< FAILURE! 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). 12:55:18 at org.junit.Assert.fail(Assert.java:88) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) 12:55:18 12:55:18 testJournalObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 29.533 sec <<< FAILURE! 12:55:18 org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> 12:55:18 at org.junit.Assert.assertEquals(Assert.java:115) 12:55:18 at org.junit.Assert.assertEquals(Assert.java:144) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) 12:55:18 12:55:18 testUseJdbcStoreWithoutDatasource(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 27.734 sec <<< FAILURE! 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ 12:55:18 (\"subsystem\" => \"datasources\"), 12:55:18 (\"data-source\" => \"ObjectStoreTestDS\") 12:55:18 ]"}} 12:55:18 at org.junit.Assert.fail(Assert.java:88) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) {noformat} Standard output: {noformat} 12:52:47,276 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:52:47,545 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:52:47,560 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] 12:52:48,082 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta12-redhat-1 12:52:48,164 INFO [org.xnio] (main) XNIO version 3.4.3.Final-redhat-1 12:52:48,287 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 12:52:49,068 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m12:52:51,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:52:53,468 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:52:54,015 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:52:54,668 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:52:59,007 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:52:59,191 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 10) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:00,425 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:00,462 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:00,507 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:00,832 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:00,925 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:53:00,931 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:01,147 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:53:01,159 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:53:01,209 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:01,309 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:01,317 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[33m12:53:01,454 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:01,512 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:01,545 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:01,733 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:01,801 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:53:02,025 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:02,027 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:02,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:02,479 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:02,833 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:02,834 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:03,020 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:03,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:03,091 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:03,447 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:03,696 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:03,723 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:03,772 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:04,334 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:04,335 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:04,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:05,306 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:05,331 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:05,575 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:05,581 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:05,883 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:53:08,210 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 19241ms - Started 351 of 670 services (471 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:08,215 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:14,504 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:53:15,001 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } &#27;[0m12:53:15,570 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m12:53:16,773 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:17,319 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } &#27;[0m12:53:17,429 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:17,430 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:17,433 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:17,439 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:17,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:17,511 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:17,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:17,514 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:17,515 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:17,426 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:17,572 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:17,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:17,623 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:17,672 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:17,870 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:18,039 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 696ms &#27;[0m&#27;[0m12:53:18,042 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:53:19,098 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:19,281 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:20,041 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:20,160 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:20,219 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:20,196 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:20,274 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:20,282 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:20,306 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:20,314 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:20,329 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:20,344 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[33m12:53:20,348 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:20,359 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:53:20,579 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:20,606 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:20,608 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:20,613 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:20,642 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:20,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:20,646 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:20,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:20,759 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:20,769 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:20,773 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:20,768 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:20,843 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:22,444 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:22,447 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:22,448 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:22,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:22,479 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[33m12:53:23,156 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getWrappedConnection(BaseWrapperManagedConnection.java:1203) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getConnection(BaseWrapperManagedConnection.java:462) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.openConnection(XAResourceRecoveryImpl.java:438) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:199) at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:348) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) ... 10 more &#27;[0m&#27;[33m12:53:23,161 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:563) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.jca.core.recovery.DefaultRecoveryPlugin.close(DefaultRecoveryPlugin.java:107) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.closeConnection(XAResourceRecoveryImpl.java:469) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:212) at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:348) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) ... 17 more &#27;[0m&#27;[0m12:53:23,749 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 4,5,management-handler-thread] &#27;[0m&#27;[0m12:53:24,045 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:24,078 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:53:24,099 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 6053ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:24,326 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:53:24,382 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:53:24,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:24,572 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:24,574 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:24,765 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:24,828 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:24,857 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:24,860 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:24,965 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:24,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:24,972 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:24,973 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:24,978 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:25,073 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 492ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore* StackTrace: {noformat} org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) {noformat} Standard output: {noformat} 12:53:25,500 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:53:25,523 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:53:25,547 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] &#27;[0m12:53:28,442 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:53:31,091 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:53:31,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:53:32,467 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:53:37,670 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:37,965 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:53:40,066 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:53:40,279 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:40,364 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[33m12:53:40,699 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:53:40,791 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:53:40,824 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:53:40,920 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:53:40,941 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:53:41,430 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:53:41,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:53:41,489 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:53:41,508 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:53:41,678 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:53:41,691 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:53:41,701 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:53:41,905 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:53:41,912 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:53:41,909 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:53:42,064 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:53:42,159 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:53:42,659 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:43,061 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:53:43,209 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:53:43,362 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:53:43,363 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:53:44,187 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:44,206 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:44,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:44,295 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:53:44,304 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:53:46,834 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:46,835 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:46,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:46,989 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:53:47,003 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:53:47,005 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:53:47,364 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:48,055 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:53:50,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:53:50,640 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:53:50,641 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 24187ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:53:50,642 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m12:53:51,263 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:53:51,444 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "jdbc" } 12:53:51,506 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "jdbc" } 12:53:52,356 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:52,835 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,259 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,715 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } 12:53:53,775 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:53:53,803 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:53:53,873 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:53:54,090 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:53:54,152 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:53:54,154 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:53:54,346 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:53:54,414 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:53:54,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:53:54,539 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:53:54,601 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:53:54,627 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:53:54,536 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:53:54,630 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:53:54,633 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:53:54,665 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:53:54,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:53:54,738 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 533ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ (\"subsystem\" => \"datasources\"), (\"data-source\" => \"ObjectStoreTestDS\") ]"}} at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) {noformat} Standard output: {noformat} 12:53:54,968 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:53:54,976 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:53:54,996 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] &#27;[0m12:53:57,625 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 &#27;[0m&#27;[0m12:54:00,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 &#27;[0m&#27;[0m12:54:00,857 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting &#27;[0m&#27;[0m12:54:01,702 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:54:06,509 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:54:06,719 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 22) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:54:08,905 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:54:09,017 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:09,056 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:09,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:54:09,652 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:54:09,658 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:54:09,699 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[33m12:54:09,791 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:54:09,859 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:54:09,918 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:54:10,021 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:54:10,083 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) &#27;[0m&#27;[0m12:54:10,150 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:54:10,161 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:54:10,371 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:54:10,372 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:54:10,449 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:54:10,938 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 &#27;[0m&#27;[0m12:54:11,007 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:54:11,381 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:54:12,044 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:54:12,045 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:54:12,049 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:54:12,572 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:54:13,204 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:54:13,207 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:54:13,232 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:54:13,239 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:54:13,246 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 &#27;[0m&#27;[0m12:54:13,290 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 &#27;[0m&#27;[0m12:54:13,573 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:54:13,608 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:54:13,614 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:54:14,914 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:54:15,209 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:54:15,212 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:54:15,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:54:16,087 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management &#27;[0m&#27;[0m12:54:19,471 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 &#27;[0m&#27;[0m12:54:19,472 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 23779ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) &#27;[0m12:54:20,014 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:54:20,148 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:54:20,584 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:54:21,270 INFO [org.jboss.as.cli.CommandContext] (main) operation-requires-reload: true process-state: reload-required 12:54:21,342 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:54:21,433 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:54:21,498 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:54:21,698 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:54:21,775 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:54:21,777 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:54:21,976 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS &#27;[0m&#27;[0m12:54:22,019 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:54:22,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:54:22,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:54:22,166 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:54:22,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 &#27;[0m&#27;[0m12:54:22,173 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 &#27;[0m&#27;[0m12:54:22,180 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:54:22,246 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:54:22,247 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 &#27;[0m&#27;[0m12:54:22,323 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:54:22,428 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 611ms &#27;[0m {noformat} *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore* StackTrace: {noformat} java.lang.AssertionError: Failed to execute line '/subsystem=transactions/log-store=log-store:read-attribute(name=type)': org.jboss.as.cli.CommandFormatException: No connection to the controller. at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.readObjectStoreType(ObjectStoreTypeTestCase.java:265) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:275) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:271) at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore(ObjectStoreTypeTestCase.java:89) {noformat} Standard output: {noformat} 12:03:49,027 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance 12:03:49,033 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. 12:03:49,036 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:196, -Dnode1=2620:52:0:105f::ffff:197, -Dmcast=ff0e:52:0:105f::ffff:199, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-12, -c=standalone-ha.xml] &#27;[0m12:03:50,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1 &#27;[0m&#27;[0m12:03:53,752 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1 &#27;[0m&#27;[0m12:03:54,152 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting &#27;[0m&#27;[0m12:03:54,774 INFO [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider &#27;[0m&#27;[0m12:03:59,746 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:03:59,994 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1 &#27;[0m&#27;[0m12:03:59,996 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 6) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 &#27;[0m&#27;[0m12:04:00,083 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 28) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:01,997 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:04:02,081 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:04:02,112 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 &#27;[0m&#27;[0m12:04:02,472 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:04:02,526 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[33m12:04:02,569 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:04:02,942 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 49) WFLYJSF0007: Activated the following JSF Implementations: [main] &#27;[0m&#27;[0m12:04:02,994 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:04:03,030 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:04:03,072 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:04:03,084 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:04:03,094 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[0m12:04:03,134 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 &#27;[0m&#27;[0m12:04:03,602 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:04:03,688 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) &#27;[0m&#27;[0m12:04:04,386 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:04:04,555 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:04,556 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:04:04,628 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:04:04,804 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:04:04,871 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:04:04,899 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:05,546 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:04:06,048 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:06,116 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:04:06,279 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 &#27;[0m&#27;[0m12:04:06,302 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:06,494 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:06,813 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:07,765 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:04:07,962 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:04:07,965 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:04:08,245 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:08,821 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) &#27;[0m&#27;[0m12:04:11,110 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:04:11,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management &#27;[0m&#27;[0m12:04:11,148 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 &#27;[0m&#27;[0m12:04:11,149 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 21534ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) &#27;[0m12:04:11,579 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. 12:04:11,637 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "result" => "default" } 12:04:12,297 INFO [org.jboss.as.cli.CommandContext] (main) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } } &#27;[0m12:04:12,438 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:12,439 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:12,459 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:12,466 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:04:12,473 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:04:12,474 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:12,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:04:12,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:12,491 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:04:12,550 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:12,676 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:04:12,678 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:12,688 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:04:12,936 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:12,984 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 670ms &#27;[0m&#27;[0m12:04:12,988 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting &#27;[0m&#27;[0m12:04:14,141 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:14,319 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 14) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 &#27;[0m&#27;[0m12:04:14,346 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. &#27;[0m&#27;[0m12:04:14,928 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) &#27;[0m&#27;[0m12:04:15,085 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem &#27;[0m&#27;[0m12:04:15,088 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 &#27;[0m&#27;[33m12:04:15,097 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. &#27;[0m&#27;[0m12:04:15,123 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. &#27;[0m&#27;[0m12:04:15,155 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem &#27;[0m&#27;[0m12:04:15,161 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension &#27;[0m&#27;[0m12:04:15,176 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors &#27;[0m&#27;[0m12:04:15,211 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. &#27;[0m&#27;[0m12:04:15,237 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) &#27;[0m&#27;[0m12:04:15,241 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting &#27;[0m&#27;[0m12:04:15,306 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service &#27;[0m&#27;[0m12:04:15,345 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. &#27;[0m&#27;[0m12:04:15,347 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. &#27;[0m&#27;[0m12:04:15,268 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] &#27;[0m&#27;[0m12:04:15,674 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] &#27;[0m&#27;[0m12:04:15,675 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. &#27;[0m&#27;[0m12:04:15,701 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:15,702 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting &#27;[0m&#27;[0m12:04:15,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:15,826 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 &#27;[0m&#27;[0m12:04:15,831 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 &#27;[0m&#27;[0m12:04:15,896 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) &#27;[0m&#27;[0m12:04:15,929 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:16,002 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:16,006 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:15,937 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:16,815 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none &#27;[0m&#27;[33m12:04:16,852 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost &#27;[0m&#27;[0m12:04:16,854 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments &#27;[0m&#27;[0m12:04:16,892 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:16,895 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) &#27;[0m12:04:18,708 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance &#27;[0m12:04:18,760 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 5768ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) &#27;[0m&#27;[0m12:04:18,767 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server &#27;[0m&#27;[0m12:04:18,906 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0236: Suspending server with no timeout. &#27;[0m&#27;[0m12:04:18,964 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' &#27;[0m&#27;[0m12:04:19,116 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] &#27;[0m&#27;[0m12:04:19,139 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] &#27;[0m&#27;[0m12:04:19,140 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] &#27;[0m&#27;[0m12:04:19,236 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping &#27;[0m&#27;[0m12:04:19,244 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown &#27;[0m&#27;[0m12:04:19,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending &#27;[0m&#27;[0m12:04:19,369 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 &#27;[0m&#27;[0m12:04:19,370 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending &#27;[0m&#27;[0m12:04:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 &#27;[0m&#27;[0m12:04:19,421 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 &#27;[0m&#27;[0m12:04:19,480 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending &#27;[0m&#27;[0m12:04:19,481 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 &#27;[0m&#27;[0m12:04:19,483 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping &#27;[0m&#27;[0m12:04:19,562 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 375ms &#27;[0m {noformat} *Expected results:* No errors > CLITestUtil should set connectionTimeout value to something more than 5 secs which is the default now > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-2600 > URL: https://issues.jboss.org/browse/WFCORE-2600 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Beta11 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > {{CLITestUtil}} creates a command context without setting any {{connectionTimeout}} for it. The default value of the {{connectionTimeout}} is 5 seconds. This value seems to be too low under some circumstances, see JBEAP-8244. > {{CLITestUtil}} at line 79 (see \[1\]) should use a different factory method to create the {{CommandContext}} and should provide a decent value for {{connectionTimeout}} too. > \[1\] https://github.com/wildfly/wildfly-core/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/management/util/CLITestUtil.java#L79 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:05:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:05:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-7987: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > Remove operations should warn the user if the resource has any dependents > ------------------------------------------------------------------------- > > Key: WFLY-7987 > URL: https://issues.jboss.org/browse/WFLY-7987 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Guillermo Gonz?lez de Ag?ero > Assignee: Tomaz Cerar > > Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects. > Take a look at this example: > {code:shell} > [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test) > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add() > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove() > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] :reload() > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:9990 /] /core-service=management:read-boot-errors() > { > "outcome" => "success", > "result" => [{ > "failed-operation" => { > "operation" => "add", > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("filter-ref" => "test") > ] > }, > "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}", > "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"] > }] > } > {code} > A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it. > The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem. > My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:06:01 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386558#comment-13386558 ] Tomaz Cerar commented on WFLY-7987: ----------------------------------- Addition of capabilities in undertow subsystem is tracked in WFLY-8473 > Remove operations should warn the user if the resource has any dependents > ------------------------------------------------------------------------- > > Key: WFLY-7987 > URL: https://issues.jboss.org/browse/WFLY-7987 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Guillermo Gonz?lez de Ag?ero > Assignee: Tomaz Cerar > > Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects. > Take a look at this example: > {code:shell} > [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test) > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add() > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove() > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] :reload() > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:9990 /] /core-service=management:read-boot-errors() > { > "outcome" => "success", > "result" => [{ > "failed-operation" => { > "operation" => "add", > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("host" => "default-host"), > ("filter-ref" => "test") > ] > }, > "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}", > "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"] > }] > } > {code} > A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it. > The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem. > My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:07:00 2017 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Thu, 30 Mar 2017 08:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2601) Adding Elytron SSO to Undertow should announce reload-required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek moved JBEAP-10024 to WFCORE-2601: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2601 (was: JBEAP-10024) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) (was: Web (Undertow)) Affects Version/s: 3.0.0.Beta10 (was: 7.1.0.DR15) > Adding Elytron SSO to Undertow should announce reload-required > -------------------------------------------------------------- > > Key: WFCORE-2601 > URL: https://issues.jboss.org/browse/WFCORE-2601 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta10 > Reporter: Ondrej Kotek > Assignee: Paul Ferraro > Priority: Blocker > Labels: authentication, http, management-model, sso, undertow > > The operation adding Elytron SSO configuration to Undertow subsystem returns {{\{"outcome" => "success"\}}}. However the SSO does not work without performing {{reload}}. It is very confusing for an administrator. > The {{reload}} should not be required, or a response header requiring reload should be returned. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:08:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7089) Undertow appears to require explicit keywords implements WebApplicationInitializer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386560#comment-13386560 ] Tomaz Cerar commented on WFLY-7089: ----------------------------------- do you have a simple reproducer? > Undertow appears to require explicit keywords implements WebApplicationInitializer > ---------------------------------------------------------------------------------- > > Key: WFLY-7089 > URL: https://issues.jboss.org/browse/WFLY-7089 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Darryl Miles > Assignee: Stuart Douglas > > Undertow appears to require explicit keywords implements WebApplicationInitializer set on WEB-INF/classes when the class is using an "extends AbstractBaseClassThatImplementWebApplicationInitializer". > It does not appear to see the annotation set on the base class AbstractBaseClassThatImplementWebApplicationInitializer. > More over in my particular scenario this base class is provided in a JAR that is inside the EAR (not the WAR). > Maybe what Wildfly is doing is completely specification compliant and other Servlet implementations work differently. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:09:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8439) Unregistering node throws error: MEM: Can't update or insert context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-8439: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > Unregistering node throws error: MEM: Can't update or insert context > -------------------------------------------------------------------- > > Key: WFLY-8439 > URL: https://issues.jboss.org/browse/WFLY-8439 > Project: WildFly > Issue Type: Bug > Components: mod_cluster, Web (Undertow) > Reporter: Stuart Douglas > Assignee: Tomaz Cerar > Labels: mod_cluster > Fix For: 11.0.0.Beta1 > > > New error message in proxy balancer log > {noformat} > 2017-03-21 15:22:24,957 INFO [io.undertow] (default task-23) UT005047: Unregistering context wildfly-services, from node jboss-eap-7.1-1 > 2017-03-21 15:22:24,962 ERROR [io.undertow] (default task-23) UT005043: Error in processing MCMP commands: Type:MEM, Mess: MEM: Can't update or insert context > 2017-03-21 15:22:28,694 INFO [io.undertow] (default task-29) UT005047: Unregistering context wildfly-services, from node jboss-eap-7.1-2 > 2017-03-21 15:22:28,696 ERROR [io.undertow] (default task-29) UT005043: Error in processing MCMP commands: Type:MEM, Mess: MEM: Can't update or insert context > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:14:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6411) Deploying and undeploying default web application with welcome root results in 404 (instead of returning content defined by welcome-content handler) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-6411: --------------------------------- Fix Version/s: 11.0.0.Alpha1 Assignee: Stuart Douglas (was: Tomas Hofman) Resolution: Done > Deploying and undeploying default web application with welcome root results in 404 (instead of returning content defined by welcome-content handler) > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6411 > URL: https://issues.jboss.org/browse/WFLY-6411 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Tomas Hofman > Assignee: Stuart Douglas > Priority: Optional > Fix For: 11.0.0.Alpha1 > > > * When I install EAP and access http://localhost:8080/ welcome page is returned. - OK > * When I deploy my custom web application with the app defined for root context => in jboss-web.xml there is defined {{/}}, after accessing http://localhost:8080/ the content of my application is returned. - OK > * When I undeploy the previously custom application used as default welcome page and try to access http://localhost:8080/, the 404 is returned (I would expect 200 is returned with the original welcome page defined by the welcome-file handler. > Note: Reloading the server configuration makes the original welcome page again accessible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:16:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-5512) Issue for pre-compiled jsp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFLY-5512. ------------------------------- Fix Version/s: 10.0.0.Final Assignee: Tomaz Cerar (was: Jason Greene) Resolution: Done Reopen if problem still exists > Issue for pre-compiled jsp > -------------------------- > > Key: WFLY-5512 > URL: https://issues.jboss.org/browse/WFLY-5512 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.1.Final > Environment: WildFly 9.0.1 > Reporter: Pradeep Pantula > Assignee: Tomaz Cerar > Priority: Minor > Labels: jboss, new_and_noteworthy, wildfly > Fix For: 10.0.0.Final > > > Issue in pre-compiled jsp file. > I have compiled jsp files using tomat and jasper libraries. It worked well with jboss7. > Now we are migrating to WildFly9. But after deployment I'm facing following issue at runtime. > Can anyone help me to solve this issue? > Pasted complete exception in here: > 17:33:00,583 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /app/obp/pages/NoService.jsp: javax.servlet.ServletException: javax.servlet.ServletException: java.lang.RuntimeException: java.lang.ClassCastException: org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager cannot be cast to org.apache.tomcat.InstanceManager > at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) > at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1858) > at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:446) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.servlet.ServletException: java.lang.RuntimeException: java.lang.ClassCastException: org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager cannot be cast to org.apache.tomcat.InstanceManager > at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) > at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1858) > at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:446) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) > at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:195) > at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) > at org.apache.struts.chain.commands.servlet.PerformForward.handleAsForward(PerformForward.java:99) > at org.apache.struts.chain.commands.servlet.PerformForward.perform(PerformForward.java:82) > at org.apache.struts.chain.commands.AbstractPerformForward.execute(AbstractPerformForward.java:51) > at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:48) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) > at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:304) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) > at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:280) > ... 31 more > Caused by: java.lang.RuntimeException: java.lang.ClassCastException: org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager cannot be cast to org.apache.tomcat.InstanceManager > at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:219) > at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) > at org.apache.struts.chain.commands.servlet.PerformForward.handleAsForward(PerformForward.java:99) > at org.apache.struts.chain.commands.servlet.PerformForward.perform(PerformForward.java:82) > at org.apache.struts.chain.commands.AbstractPerformForward.execute(AbstractPerformForward.java:51) > at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:48) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) > at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:304) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) > at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:280) > ... 53 more > Caused by: java.lang.ClassCastException: org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager cannot be cast to org.apache.tomcat.InstanceManager > at org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(InstanceManagerFactory.java:32) > at org.apache.jsp.pages.NoService_jsp._jspInit(Unknown Source) > at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) > at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:169) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) > at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:195) > ... 62 more > 17:33:00,600 ERROR [io.undertow.request] (default task-1) UT005022: Exception generating error page /pages/customer/500.jsp: java.lang.RuntimeException: java.lang.ClassCastException: org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager cannot be cast to org.apache.tomcat.InstanceManager > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:475) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:388) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:309) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.ClassCastException: org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager cannot be cast to org.apache.tomcat.InstanceManager > at org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(InstanceManagerFactory.java:32) > at org.apache.jasper.runtime.TagHandlerPool.init(TagHandlerPool.java:83) > at org.apache.jasper.runtime.TagHandlerPool.getTagHandlerPool(TagHandlerPool.java:63) > at org.apache.jsp.pages.customer._500_jsp._jspInit(Unknown Source) > at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) > at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:169) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:469) > ... 10 more > Thanks in Advance, > Pradeep. P -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 08:20:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 08:20:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8474) Adding Elytron SSO to Undertow should announce reload-required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved WFCORE-2601 to WFLY-8474: ------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-8474 (was: WFCORE-2601) Component/s: Security Web (Undertow) (was: Security) Affects Version/s: (was: 3.0.0.Beta10) > Adding Elytron SSO to Undertow should announce reload-required > -------------------------------------------------------------- > > Key: WFLY-8474 > URL: https://issues.jboss.org/browse/WFLY-8474 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Ondrej Kotek > Assignee: Paul Ferraro > Priority: Blocker > Labels: authentication, http, management-model, sso, undertow > > The operation adding Elytron SSO configuration to Undertow subsystem returns {{\{"outcome" => "success"\}}}. However the SSO does not work without performing {{reload}}. It is very confusing for an administrator. > The {{reload}} should not be required, or a response header requiring reload should be returned. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 09:15:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Thu, 30 Mar 2017 09:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8475) JBoss-Product-Release-Name has changed in eap manifest, breaking tools expectations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet moved JBEAP-10027 to WFLY-8475: ------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8475 (was: JBEAP-10027) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Productization) Affects Version/s: 11.0.0.Alpha1 (was: 7.0.0.ER6) > JBoss-Product-Release-Name has changed in eap manifest, breaking tools expectations > ----------------------------------------------------------------------------------- > > Key: WFLY-8475 > URL: https://issues.jboss.org/browse/WFLY-8475 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 11.0.0.Alpha1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > See https://issues.jboss.org/browse/JBIDE-21782 > JBossTools was keying off JBoss-Product-Release-Name and matching it to "EAP" so we know how tools should handle this server, set minimum java requirements, etc. > The change to "JBoss EAP" broke expectations. Admittedly we can fix it now, but should tools be expecting that this release-name will remain mostly stable? Or should we expect it to change often? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 09:42:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 09:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-1) [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386644#comment-13386644 ] Hayk Hovsepyan commented on HAWKULARQE-1: ----------------------------------------- Development tasks are done here. Testing process can be started. > [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-1 > URL: https://issues.jboss.org/browse/HAWKULARQE-1 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 09:53:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 09:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-1) [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386659#comment-13386659 ] Hayk Hovsepyan commented on HAWKULARQE-1: ----------------------------------------- Taking this task on me to be done. > [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-1 > URL: https://issues.jboss.org/browse/HAWKULARQE-1 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 09:53:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 09:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-1) [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-1: --------------------------------------- Assignee: Hayk Hovsepyan (was: Prachi Yadav) > [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-1 > URL: https://issues.jboss.org/browse/HAWKULARQE-1 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 10:06:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 10:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2181) Server doesn't start on Windows when started from path that contains space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reopened WFCORE-2181: --------------------------------- > Server doesn't start on Windows when started from path that contains space > -------------------------------------------------------------------------- > > Key: WFCORE-2181 > URL: https://issues.jboss.org/browse/WFCORE-2181 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Fix For: 3.0.0.Alpha18 > > > If one installs his EAP(on Windows) to the location that has a space in the path(...\Program Files\...) is then unable to start it. > This is regression against EAP 7.0.0 and 7.1.0.DR7. > This issue could be caused by JBEAP-6182 ([https://github.com/wildfly/wildfly-core/pull/1886/files]) > Following error is printed > {noformat} > Error: Could not find or load main class Files\ModCluster_Workspace\jboss-eap-7.1\standalone\log\gc.log > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 10:13:01 2017 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Thu, 30 Mar 2017 10:13:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386674#comment-13386674 ] Stefano Maestri commented on JBJCA-1341: ---------------------------------------- [~jolee] yup it's what I've written. Maybe is not so easy to read because I've written all option on the same line just separating them by a column. Editing to make it more readable > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 10:18:00 2017 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Thu, 30 Mar 2017 10:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8476) Upgrade Artemis 1.5.3.jbossorg-004 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil moved JBEAP-10031 to WFLY-8476: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8476 (was: JBEAP-10031) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) > Upgrade Artemis 1.5.3.jbossorg-004 > ---------------------------------- > > Key: WFLY-8476 > URL: https://issues.jboss.org/browse/WFLY-8476 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 10:26:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 10:26:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8477) Introduce capabilites in undertow subsystem In-Reply-To: References: Message-ID: Tomaz Cerar created WFLY-8477: --------------------------------- Summary: Introduce capabilites in undertow subsystem Key: WFLY-8477 URL: https://issues.jboss.org/browse/WFLY-8477 Project: WildFly Issue Type: Enhancement Reporter: Tomaz Cerar Assignee: Tomaz Cerar Majority of undertow subsystem should move to capabilites. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:04:03 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 11:04:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8478) Setting elytron ssl-context on undertow without reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved WFCORE-2448 to WFLY-8478: ------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-8478 (was: WFCORE-2448) Component/s: Security Web (Undertow) (was: Security) Affects Version/s: (was: 3.0.0.Beta7) > Setting elytron ssl-context on undertow without reload > ------------------------------------------------------ > > Key: WFLY-8478 > URL: https://issues.jboss.org/browse/WFLY-8478 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Martin Choma > Assignee: Tomaz Cerar > Labels: user_experience > > Please, allow setting of elytron ssl-context on undertow without reload. > {code} > [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=server) > { > ????"outcome" => "success", > ????"response-headers" => { > ????????"operation-requires-reload" => true, > ????????"process-state" => "reload-required" > ????} > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:12:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 11:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8478) Setting elytron ssl-context on undertow without reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-8478. ----------------------------- Resolution: Rejected You need to pass {allow-resource-service-restart=true} header to operation if you want to have runtime change without reload > Setting elytron ssl-context on undertow without reload > ------------------------------------------------------ > > Key: WFLY-8478 > URL: https://issues.jboss.org/browse/WFLY-8478 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Martin Choma > Assignee: Tomaz Cerar > Labels: user_experience > > Please, allow setting of elytron ssl-context on undertow without reload. > {code} > [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=server) > { > ????"outcome" => "success", > ????"response-headers" => { > ????????"operation-requires-reload" => true, > ????????"process-state" => "reload-required" > ????} > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:16:00 2017 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 30 Mar 2017 11:16:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7456) Inconsistent description for custom mail server between :read-resource-description on parent and the custom server itself In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar closed WFLY-7456. ----------------------------- Resolution: Rejected > Inconsistent description for custom mail server between :read-resource-description on parent and the custom server itself > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7456 > URL: https://issues.jboss.org/browse/WFLY-7456 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 10.1.0.Final > Reporter: Radim Hatlapatka > Assignee: Tomaz Cerar > Priority: Optional > Labels: user_experience > > There is inconsistent description for custom server when reading it as child description => {{/subsystem=mail/mail-session=default:read-resource-description}}, where it is {{Custom mail server configuration}} and when reading its description directly => {{/subsystem=mail/mail-session=default/custom=xxx:read-resource-description}}, where it is {{Mail session server}} > This doesn't look nice from UX PoV, where I believe these values should be the same. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:17:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Thu, 30 Mar 2017 11:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-72) Polarion data cleanup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386732#comment-13386732 ] Sunil kondkar commented on HAWKULARQE-72: ----------------------------------------- All work related to test cases is done. Worked on linking requirements to test cases marking them as 'verifies' the test case rather than 'relates' is done. ( This is causing missing data in most of the projects) Created a doc mentioning some guidelines. http://pad.engineering.redhat.com/PolarionGuidelines The following report does not show any missing data. https://polarion.engineering.redhat.com/polarion/#/project/pylarion/wiki/Report%20Testing/Test_Case_Quality_audit_report?Project=JBossON4 While going through EAP project reports, observed that there are release plans created in Polarion and requirements are marked as 'planned in' which is not in our case. ( These plans are different from test plans) Created few release plans like: Parent: MM-CFME58 Child plans: MM-CFME58-DR1, MM-CFME58-DR2 and MM-CFME58-DR3 link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans Now the remaining task is: Research and link requirements/test cases to the respective plans in Polarion so as to enble reports viewing according to Polarion plans. > Polarion data cleanup > --------------------- > > Key: HAWKULARQE-72 > URL: https://issues.jboss.org/browse/HAWKULARQE-72 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to able to have polarion reports in place. > Reports: > 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics > 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports > 3) Test Run Status by Plan > 4) Test Run Status by Plan and chosen fields > Tasks: > 1) Find and remove duplicates > 2) Each test case has correct fields > * Description > * Level > * Test type and sub type > * Automated or Manual > * Importance (Severity) > 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) > Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans > 4) Check if manual test cases are with approved status( Approve if needed) > 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. > (Need to check if we can have the polarion export job marking it Approved while executed going forward?) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:27:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 11:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-3) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386741#comment-13386741 ] Hayk Hovsepyan commented on HAWKULARQE-3: ----------------------------------------- Manual testcase is reviewed and changed: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10041 > Manual Testcases - Create and Run > --------------------------------- > > Key: HAWKULARQE-3 > URL: https://issues.jboss.org/browse/HAWKULARQE-3 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Labels: hawkular-qe-manual > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:27:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 11:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-3) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-3: --------------------------------------- Assignee: Hayk Hovsepyan (was: Prachi Yadav) > Manual Testcases - Create and Run > --------------------------------- > > Key: HAWKULARQE-3 > URL: https://issues.jboss.org/browse/HAWKULARQE-3 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Labels: hawkular-qe-manual > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:27:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 11:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-4) Automate Testcases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-4: --------------------------------------- Assignee: Hayk Hovsepyan (was: Prachi Yadav) > Automate Testcases > ------------------ > > Key: HAWKULARQE-4 > URL: https://issues.jboss.org/browse/HAWKULARQE-4 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Labels: hawkular-qe-automation > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:30:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Thu, 30 Mar 2017 11:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-82) JMAN4 Feature Requests Test Cases Review In-Reply-To: References: Message-ID: Hayk Hovsepyan created HAWKULARQE-82: ---------------------------------------- Summary: JMAN4 Feature Requests Test Cases Review Key: HAWKULARQE-82 URL: https://issues.jboss.org/browse/HAWKULARQE-82 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Priority: Critical Go through all JMAN4 Features and their QE tasks: Make sure that all existing Polarion testcases are created and mentioned in QE tasks. Review polarion testcases, make comments on QE tasks to fix testcases if necessary. If testcases are missing, request to create them. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 11:58:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 11:58:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8478) Setting elytron ssl-context on undertow without reload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386759#comment-13386759 ] Brian Stansberry commented on WFLY-8478: ---------------------------------------- This is true, but we should be careful about simple advice to use {allow-resource-service-restart=true}. That's a power user setting that should only be used by people with a very clear understanding of the effects. It's not in any way a "better reload". In this case {allow-resource-service-restart=true} is likely more useful, since I don't *think* bouncing the listener service will have widely cascading effects. But any advice to use {allow-resource-service-restart=true} should always include some comment on what the expected effects would be. The end user will very likely not have a clue and an uneducated guess will likely be too optimistic by far. BTW, I'm not arguing with rejecting this issue if there is no reasonable way to update the service without a service restart. And I have reason to believe there is such a way. My point is just about what message we send to end users. > Setting elytron ssl-context on undertow without reload > ------------------------------------------------------ > > Key: WFLY-8478 > URL: https://issues.jboss.org/browse/WFLY-8478 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Martin Choma > Assignee: Tomaz Cerar > Labels: user_experience > > Please, allow setting of elytron ssl-context on undertow without reload. > {code} > [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=server) > { > ????"outcome" => "success", > ????"response-headers" => { > ????????"operation-requires-reload" => true, > ????????"process-state" => "reload-required" > ????} > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 12:17:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 30 Mar 2017 12:17:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1014) Elytron auth method misconfiguration not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated ELY-1014: ---------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/746 (was: https://github.com/wildfly-security/wildfly-elytron/pull/732) > Elytron auth method misconfiguration not logged > ----------------------------------------------- > > Key: ELY-1014 > URL: https://issues.jboss.org/browse/ELY-1014 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Labels: user_experience > > When deployment is configured to be secured with DIGEST, but {{http-authentication-factory}} does not list DIGEST mechanism, user is not informed about misconfiguration. Even when TRACE logging is turned on. When user tries to access app 403 http code is returned and Forbidden is shown in browser. I would expect browser dialog to appear to allow user provide credentials (401 http status code). > {code:title=web.xml} > > DIGEST > ApplicaitonRealm > > {code} > {code:title=standalone-elytron.xml} > > > > > > > > > {code} > This applies globally to all authentication mechanisms, not only DIGEST. > Could elytron handle misconfiguration: > * either fail during deploying application as deployment requirement can't be satisfy > * or provide reasonable elytron defaults of missing mechanism configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 12:43:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 12:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1032) Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned ELY-1032: ------------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option. > ------------------------------------------------------------------------------------------------------------ > > Key: ELY-1032 > URL: https://issues.jboss.org/browse/ELY-1032 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Fix For: 1.1.0.Beta34 > > > Help output has limit 160 chars for line length and it leads to ugly line break in the middle of one option. > Command > {code} > java -jar wildfly-elytron-tool.jar credential-store --help > {code} > has this output: > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store -a | -e | -h | -r | -v [-c] [-f] [-i ] [-l ] [-p ] [-s > ] [-t ] [-u ] [-x ] > {code} > I expect at least line break before "-s" option > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store -a | -e | -h | -r | -v [-c] [-f] [-i ] [-l ] [-p ] > [-s ] [-t ] [-u ] [-x ] > {code} > The best option would be some dynamic settings of line length -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 12:43:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 12:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1032) Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1032: ---------------------------------- Fix Version/s: 1.1.0.Beta34 > Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option. > ------------------------------------------------------------------------------------------------------------ > > Key: ELY-1032 > URL: https://issues.jboss.org/browse/ELY-1032 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek ?v?bek > Assignee: Peter Skopek > Fix For: 1.1.0.Beta34 > > > Help output has limit 160 chars for line length and it leads to ugly line break in the middle of one option. > Command > {code} > java -jar wildfly-elytron-tool.jar credential-store --help > {code} > has this output: > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store -a | -e | -h | -r | -v [-c] [-f] [-i ] [-l ] [-p ] [-s > ] [-t ] [-u ] [-x ] > {code} > I expect at least line break before "-s" option > {code} > usage: java -jar wildfly-elytron-tool.jar credential-store -a | -e | -h | -r | -v [-c] [-f] [-i ] [-l ] [-p ] > [-s ] [-t ] [-u ] [-x ] > {code} > The best option would be some dynamic settings of line length -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 12:44:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 12:44:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1045) Release WildFly Elytron 1.1.0.Beta34 In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-1045: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta34 Key: ELY-1045 URL: https://issues.jboss.org/browse/ELY-1045 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta34 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:02:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:02:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2602) Upgrade WildFly Elytron to 1.1.0.Beta34 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2602: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta34 Key: WFCORE-2602 URL: https://issues.jboss.org/browse/WFCORE-2602 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:03:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:03:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2603) Upgrade WildFly Elytron Tool to 1.0.0.Beta1 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-2603: ---------------------------------------- Summary: Upgrade WildFly Elytron Tool to 1.0.0.Beta1 Key: WFCORE-2603 URL: https://issues.jboss.org/browse/WFCORE-2603 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta12 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:09:00 2017 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 30 Mar 2017 13:09:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-1471. --------------------------------- Resolution: Rejected Serialization requires a snapshot of the session, so it can't be done while a fireUntilHalt is concurrently running. > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final, 6.5.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:13:00 2017 From: issues at jboss.org (R Searls (JIRA)) Date: Thu, 30 Mar 2017 13:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8479) add jaxrs integration tests to check registration of resources in mgt model In-Reply-To: References: Message-ID: R Searls created WFLY-8479: ------------------------------ Summary: add jaxrs integration tests to check registration of resources in mgt model Key: WFLY-8479 URL: https://issues.jboss.org/browse/WFLY-8479 Project: WildFly Issue Type: Task Components: REST Affects Versions: 11.0.0.Beta1 Reporter: R Searls Assignee: R Searls Priority: Trivial WFLY-8026 was about proper registration of jaxrs app resources in the mgt model. It is desirable to added integration tests to confirm registration is working with the various ways a REST app can be defined. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:18:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1045) Release WildFly Elytron 1.1.0.Beta34 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved ELY-1045. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta34 > ------------------------------------ > > Key: ELY-1045 > URL: https://issues.jboss.org/browse/ELY-1045 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:19:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1030: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > Move TokenSecurityRealm to org.wildfly.security.auth.realm package > ------------------------------------------------------------------ > > Key: ELY-1030 > URL: https://issues.jboss.org/browse/ELY-1030 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta35 > > > The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:19:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1031) Make the CredentialStore class final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1031: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > Make the CredentialStore class final > ------------------------------------ > > Key: ELY-1031 > URL: https://issues.jboss.org/browse/ELY-1031 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Priority: Critical > Fix For: 1.1.0.Beta35 > > > Unless there is a reason this has not already be done the class should probably be made final to be sure extension is not possible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:19:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1028) AuthenticationException should extend IOException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1028: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > AuthenticationException should extend IOException > ------------------------------------------------- > > Key: ELY-1028 > URL: https://issues.jboss.org/browse/ELY-1028 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta35 > > > Remote authentications use I/O. AuthenticationException pertains solely to remote authentications. Therefore it (like SaslException and many others) should extend IOException, not GeneralSecurityException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:19:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 13:19:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1029) Support clients that provide an optional CallbackHandler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated ELY-1029: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > Support clients that provide an optional CallbackHandler > -------------------------------------------------------- > > Key: ELY-1029 > URL: https://issues.jboss.org/browse/ELY-1029 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta35 > > > Clients such as the WildFly CLI provide a CallbackHandler implementation in case it is needed and not as a sign that it must be used, i.e. the desired outcome is that if the information required can be obtained from the configuration then authentication proceeds without interaction with the end user. > Neither the CLI or the end user should be required to be fully aware of the underlying security configuration. > This is similar to web browser HTTP authentication where there is only an interaction with the user if actually required. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:50:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 13:50:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-2217: ------------------------------------- Issue Type: Bug (was: Component Upgrade) > ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests > ----------------------------------------------------------------------------------- > > Key: WFCORE-2217 > URL: https://issues.jboss.org/browse/WFCORE-2217 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Kabir Khan > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java#L495 which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java#L523 does not get called. > The fix is quite simple: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set validateAddresses = new HashSet(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set validateAddresses = new HashSet(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full. > I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives. > For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set validateAddresses = new HashSet(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set validateAddresses = new HashSet(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > So although the fix is simple, the fallout of this is quite big. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:51:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 13:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2605) Upgrade DMR to 1.4.0.Final In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2605: ---------------------------------------- Summary: Upgrade DMR to 1.4.0.Final Key: WFCORE-2605 URL: https://issues.jboss.org/browse/WFCORE-2605 Project: WildFly Core Issue Type: Component Upgrade Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Beta12 Just a pom change to the currently used 1.4.0.Beta2 to promote it to final. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 13:51:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 13:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2604) Upgrade DMR to 1.4.0.Final In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-2604: ---------------------------------------- Summary: Upgrade DMR to 1.4.0.Final Key: WFCORE-2604 URL: https://issues.jboss.org/browse/WFCORE-2604 Project: WildFly Core Issue Type: Component Upgrade Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Beta12 Just a pom change to the currently used 1.4.0.Beta2 to promote it to final. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:10:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2591) deployment add/add-content alternatives and required issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2591: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Brian Stansberry) [~ehugonnet] I think you are already looking at this. > deployment add/add-content alternatives and required issues > ----------------------------------------------------------- > > Key: WFCORE-2591 > URL: https://issues.jboss.org/browse/WFCORE-2591 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: ehsavoie Hugonnet > Priority: Minor > > add operation > - content should be required. > - alternatives hash/bytes/url/path/input-stream-index/empty should be required. > add-content operation > - content should be required. > - alternatives input-stream-index/hash/bytes/url should be required. > - alternatives empty/relative-to/path should not be present in alternatives list. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:12:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:12:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2433) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13386813#comment-13386813 ] Brian Stansberry commented on WFCORE-2433: ------------------------------------------ I submitted a PR to https://github.com/wildfly-security-incubator/wildfly-core/pull/107 > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2433 > URL: https://issues.jboss.org/browse/WFCORE-2433 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:13:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2217: ---------------------------------------- Assignee: (was: Brian Stansberry) > ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests > ----------------------------------------------------------------------------------- > > Key: WFCORE-2217 > URL: https://issues.jboss.org/browse/WFCORE-2217 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Kabir Khan > Fix For: 4.0.0.Alpha1 > > > During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java#L495 which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java#L523 does not get called. > The fix is quite simple: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set validateAddresses = new HashSet(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set validateAddresses = new HashSet(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full. > I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives. > For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set validateAddresses = new HashSet(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set validateAddresses = new HashSet(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > So although the fix is simple, the fallout of this is quite big. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:14:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:14:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2197: ---------------------------------------- Assignee: (was: Brian Stansberry) > ability to upload content from secure web server > ------------------------------------------------ > > Key: WFCORE-2197 > URL: https://issues.jboss.org/browse/WFCORE-2197 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Ian Kent > > We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:18:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2041) Improve query operation for complex attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2041: ---------------------------------------- Assignee: (was: Brian Stansberry) > Improve query operation for complex attributes > ---------------------------------------------- > > Key: WFCORE-2041 > URL: https://issues.jboss.org/browse/WFCORE-2041 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Lin Gao > > The global {{query()}} operation works only for simple attributes like: > {code:java} > [standalone at localhost:9990 /] /subsystem=datasources/jdbc-driver=*:query(select=[driver-xa-datasource-class-name], where={driver-name=h2}) > { > "outcome" => "success", > "result" => [{ > "address" => [ > ("subsystem" => "datasources"), > ("jdbc-driver" => "h2") > ], > "outcome" => "success", > "result" => {"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"} > }] > } > {code} > It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of the complex attribute+, so that, for example, the following commands can work well as expected: > {code:} > [standalone at localhost:9990 /] /core-service=capability-registry:query(select=[possible-capabilities],where={possible-capabilities.name=org.wildfly.data-source}) > {code} > {code:} > [standalone at localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"}) > {code} > The {{rest-resource-paths.resource-path}} and {{possible-capabilities.name}} in 'where' parameter are proposed attribute names in enhanced syntax, other options maybe possible too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:18:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2042) Improve query operation for nested child resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-2042: ---------------------------------------- Assignee: (was: Brian Stansberry) > Improve query operation for nested child resources > -------------------------------------------------- > > Key: WFCORE-2042 > URL: https://issues.jboss.org/browse/WFCORE-2042 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Lin Gao > > This is another similar RFE as WFCORE-2041. > It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of nested child resources(not only by the first level of child resource)+, so that, for example, the following command can work well as expected: > {code:} > [standalone at localhost:9990 /] /subsystem=security:query(select=[security-domain], where={security-domain.authentication.login-modules.code=RealmDirect}) > { > "outcome" => "success", > "result" => undefined > } > // here the expected output are the security-domain resources which have the loging-module RealmDirect defined. > {code} > The {{security-domain.authentication.login-modules.code}} in 'where' parameter is proposed attribute name in enhanced syntax, other options maybe possible. > The different requirements between this WFCORE-2042 and WFCORE-2041 are: > * WFCORE-2041 focus on complex attributes in one management resource > * WFCORE-2042 focus on nested management resources with or without complex attributes -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:21:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:21:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-6616: ----------------------------------- Issue Type: Bug (was: Feature Request) > Problems in DomainHostExcludes700TestCase > ----------------------------------------- > > Key: WFLY-6616 > URL: https://issues.jboss.org/browse/WFLY-6616 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > Labels: domain-mode > Fix For: 11.0.0.Beta1 > > > The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message: > {code} > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."}, > "rolled-back" => true > } > {code} > And we also see an error in > {code} > DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1> > {code} > Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:24:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:24:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFLY-6616: -------------------------------------- Assignee: Ken Wills (was: Brian Stansberry) [~luck3y] I'm not sure on the priority on this as I don't really understand what the problem is (not surprising given I've done zero investigation.) But I'm clearing out stuff assigned to myself and for this one rather than unassigning I figured I'd pass to you since Kabir's comment talks about ignore-unused-configuration and you're the guru on that. > Problems in DomainHostExcludes700TestCase > ----------------------------------------- > > Key: WFLY-6616 > URL: https://issues.jboss.org/browse/WFLY-6616 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Kabir Khan > Assignee: Ken Wills > Labels: domain-mode > Fix For: 11.0.0.Beta1 > > > The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message: > {code} > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."}, > "rolled-back" => true > } > {code} > And we also see an error in > {code} > DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1> > {code} > Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:25:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-1160: ---------------------------------------- Assignee: (was: Brian Stansberry) > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Labels: affects_elytron > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:27:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 14:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8480) Backport latest Elytron Integration changes In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-8480: -------------------------------------- Summary: Backport latest Elytron Integration changes Key: WFLY-8480 URL: https://issues.jboss.org/browse/WFLY-8480 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:34:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:34:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3860) Improve dependency handling in clustering/infinispan subsystem tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFLY-3860: -------------------------------------- Assignee: (was: Brian Stansberry) I'm removing myself as assignee here as I don't expect to get back to this. If you don't decide to close this please feel free to grab anything useful from the previous PR. > Improve dependency handling in clustering/infinispan subsystem tests > -------------------------------------------------------------------- > > Key: WFLY-3860 > URL: https://issues.jboss.org/browse/WFLY-3860 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > > The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started. > This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions. > Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail. > I plan to: > 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model. > 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that: > a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.) > b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy. > The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:38:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:38:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1256) To make JBOSS AS 7 node communication secure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143853#comment-13143853 ] Brian Stansberry edited comment on WFCORE-1256 at 3/30/17 2:37 PM: ------------------------------------------------------------------- Note to self: https://developer.jboss.org/thread/224208 This needs to be incorporated into the https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Domainsetup content. https://docs.jboss.org/author/display/AS7/Securing+the+Management+Interfaces has this in different form, plus some other stuff, and probably needs to be pulled forward into the 10 docs, but I want to add a very explicit doc of this particular use case. > To make JBOSS AS 7 node communication secure > --------------------------------------------- > > Key: WFCORE-1256 > URL: https://issues.jboss.org/browse/WFCORE-1256 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Environment: JBOSS AS 7.1.0 final , Windows 7 > Reporter: hitesh yadav > Assignee: Brian Stansberry > Labels: jboss > > I am using JBOSS AS 7.1.0 final in domain mode . > There are 4 node in domain. > My requirement is to make node communication secure ............like HTTPS. > As per my understanding JBOSS AS 7 uses JGroups for communication between domain node and JGroups use TCP or UDP protocol for communicate. > For example ......when we are using HTTPS protocol, all communication between Browser and Server are done in Encrypted formate........... > I need same thing in JBOSS AS 7 node communication ........means all communication between domain nodes must be done in some Encryption/Decryption form or any other way to make communication secure ...... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:39:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 14:39:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1256) To make JBOSS AS 7 node communication secure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-1256: ---------------------------------------- Assignee: (was: Brian Stansberry) Unassigning from myself as I don't see having time to do this, and the elytron work is providing alternatives anyway. Hopefully the links from my last comment are useful > To make JBOSS AS 7 node communication secure > --------------------------------------------- > > Key: WFCORE-1256 > URL: https://issues.jboss.org/browse/WFCORE-1256 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Environment: JBOSS AS 7.1.0 final , Windows 7 > Reporter: hitesh yadav > Labels: jboss > > I am using JBOSS AS 7.1.0 final in domain mode . > There are 4 node in domain. > My requirement is to make node communication secure ............like HTTPS. > As per my understanding JBOSS AS 7 uses JGroups for communication between domain node and JGroups use TCP or UDP protocol for communicate. > For example ......when we are using HTTPS protocol, all communication between Browser and Server are done in Encrypted formate........... > I need same thing in JBOSS AS 7 node communication ........means all communication between domain nodes must be done in some Encryption/Decryption form or any other way to make communication secure ...... -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:40:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 14:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2571) Enable OAUTH_BEARER SASL mechanism to CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2571: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Enable OAUTH_BEARER SASL mechanism to CLI > ----------------------------------------- > > Key: WFCORE-2571 > URL: https://issues.jboss.org/browse/WFCORE-2571 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Affects Versions: 3.0.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 3.0.0.Beta12 > > > CLI should be able to support bearer token credentials in order to support integration with OAuth2 and OpenID Connect compliant authorization servers. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:40:01 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 14:40:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2563) Missing failure description for incorrect module in Elytron dir-context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2563: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Missing failure description for incorrect module in Elytron dir-context > ----------------------------------------------------------------------- > > Key: WFCORE-2563 > URL: https://issues.jboss.org/browse/WFCORE-2563 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Labels: user_experience > Fix For: 3.0.0.Beta12 > > > In case when {{module}} attribute from Elytron {{dir-context}} includes module which does not exist, then insufficient failure description is provided - it only prints name of given module. It should rather inform that given module does not exist. > See: > {code} > /subsystem=elytron/dir-context=someDirContext:add(url=localhost,module=wrong.module) > { > "outcome" => "failed", > "failure-description" => "wrong.module", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:42:00 2017 From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=) Date: Thu, 30 Mar 2017 14:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1503) Errors when parsing item definition allowed values are not reported In-Reply-To: References: Message-ID: M?lanie Gauthier created DROOLS-1503: ---------------------------------------- Summary: Errors when parsing item definition allowed values are not reported Key: DROOLS-1503 URL: https://issues.jboss.org/browse/DROOLS-1503 Project: Drools Issue Type: Bug Components: dmn engine Reporter: M?lanie Gauthier Assignee: Edson Tirelli Attachments: WrongConstraintsInItemDefinition.dmn When validating or executing a DMN file that has something invalid in the allowedValues of an ItemDefinition, the compilation fails with no explanation. If you take the same expression and put it in the input/output values of a decision table, a message tells that this particular expression failed. The attached example has [True,False] as the allowed value of the item definition, which is invalid and prevents model compilation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:42:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 14:42:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2433) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-2433: ------------------------------------- Fix Version/s: 3.0.0.Beta12 > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2433 > URL: https://issues.jboss.org/browse/WFCORE-2433 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta12 > > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:43:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Thu, 30 Mar 2017 14:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1503) Errors when parsing item definition allowed values are not reported In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli reassigned DROOLS-1503: ------------------------------------- Assignee: Matteo Mortari (was: Edson Tirelli) > Errors when parsing item definition allowed values are not reported > ------------------------------------------------------------------- > > Key: DROOLS-1503 > URL: https://issues.jboss.org/browse/DROOLS-1503 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: M?lanie Gauthier > Assignee: Matteo Mortari > Attachments: WrongConstraintsInItemDefinition.dmn > > > When validating or executing a DMN file that has something invalid in the allowedValues of an ItemDefinition, the compilation fails with no explanation. If you take the same expression and put it in the input/output values of a decision table, a message tells that this particular expression failed. > The attached example has [True,False] as the allowed value of the item definition, which is invalid and prevents model compilation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 14:46:00 2017 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 30 Mar 2017 14:46:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8438) EJBComponentDescription : possible NPE on securityRoles In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-8438: ----------------------------------- Fix Version/s: 11.0.0.Beta1 > EJBComponentDescription : possible NPE on securityRoles > ------------------------------------------------------- > > Key: WFLY-8438 > URL: https://issues.jboss.org/browse/WFLY-8438 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 11.0.0.Beta1 > > > In https://github.com/wildfly/wildfly/commit/38f8f5915b40d036bd0fd1a904d6a13916f3fa2c#diff-faf7ca63d4b901f1bff0697491c8f5ddL1147 you added check on {{if (securityRoles != null)}}. > securityRoles is not checked few lines below your check (in different if block) > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponentDescription.java#L1162 (securityRoles.getSecurityRoleNamesByPrincipal ... ) > I suggest to change https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponentDescription.java#L1158 from > {code} > if (runAsPrincipal != null) { > {code} > to > {code} > if ((securityRoles != null) && (runAsPrincipal != null)) { > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 17:04:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 30 Mar 2017 17:04:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2181) Server doesn't start on Windows when started from path that contains space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-2181. -------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Alpha18) Resolution: Done > Server doesn't start on Windows when started from path that contains space > -------------------------------------------------------------------------- > > Key: WFCORE-2181 > URL: https://issues.jboss.org/browse/WFCORE-2181 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Fix For: 3.0.0.Beta12 > > > If one installs his EAP(on Windows) to the location that has a space in the path(...\Program Files\...) is then unable to start it. > This is regression against EAP 7.0.0 and 7.1.0.DR7. > This issue could be caused by JBEAP-6182 ([https://github.com/wildfly/wildfly-core/pull/1886/files]) > Following error is printed > {noformat} > Error: Could not find or load main class Files\ModCluster_Workspace\jboss-eap-7.1\standalone\log\gc.log > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 17:48:00 2017 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Thu, 30 Mar 2017 17:48:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3860) Improve dependency handling in clustering/infinispan subsystem tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar reassigned WFLY-3860: ------------------------------------ Assignee: Radoslav Husar > Improve dependency handling in clustering/infinispan subsystem tests > -------------------------------------------------------------------- > > Key: WFLY-3860 > URL: https://issues.jboss.org/browse/WFLY-3860 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Radoslav Husar > > The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started. > This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions. > Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail. > I plan to: > 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model. > 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that: > a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.) > b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy. > The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 19:52:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 30 Mar 2017 19:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2606) Wildfly OpenSSL 1.0.0.CR1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-10042 to WFCORE-2606: ------------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2606 (was: JBEAP-10042) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Wildfly OpenSSL 1.0.0.CR1 > ------------------------- > > Key: WFCORE-2606 > URL: https://issues.jboss.org/browse/WFCORE-2606 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 23:43:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 30 Mar 2017 23:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8481) ClassCastException upon trying to invoke asynchronous method in bean running in EAP7.1 from 7.0 legacy EJB client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-10044 to WFLY-8481: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8481 (was: JBEAP-10044) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.1.0.DR14) > ClassCastException upon trying to invoke asynchronous method in bean running in EAP7.1 from 7.0 legacy EJB client > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8481 > URL: https://issues.jboss.org/browse/WFLY-8481 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Critical > > Upon asynchronous call from 7.0 client to bean deployed on 7.1 server, the following exception is produced: > {code}Mar 17, 2017 7:25:36 AM org.jboss.as.quickstarts.ejb.asynchronous.client.AsynchronousClient fireAndForget > INFO: The server log should contain a message at (about) Fri Mar 17 07:25:51 UTC 2017, indicating that the call to the asynchronous bean completed. > Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.util.concurrent.Future > at com.sun.proxy.$Proxy0.longerRunning(Unknown Source) > at org.jboss.as.quickstarts.ejb.asynchronous.client.AsynchronousClient.getResultAsync(AsynchronousClient.java:88) > at org.jboss.as.quickstarts.ejb.asynchronous.client.AsynchronousClient.main(AsynchronousClient.java:159){code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 03:06:00 2017 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 31 Mar 2017 03:06:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1046) Elytron properties-realm doesn't handle unicode sequences In-Reply-To: References: Message-ID: Josef Cacek created ELY-1046: -------------------------------- Summary: Elytron properties-realm doesn't handle unicode sequences Key: ELY-1046 URL: https://issues.jboss.org/browse/ELY-1046 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker Users who use property-file based authentication with plain passwords can't authenticate with Elytron if the property file contains Unicode escape sequences (e.g. file generated by using a classical {{java.util.Properties}}). The same authentication works with legacy solution (_/core-service=management/security-realm=ApplicationRealm/authentication=properties(plain-text=true, ...)_). The {{LegacyPropertiesSecurityRealm}} implementation has to be able to support properties files which were supported by legacy security realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 03:53:00 2017 From: issues at jboss.org (Matteo Mortari (JIRA)) Date: Fri, 31 Mar 2017 03:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1504) Resolution of variable with leading or trailing spaces In-Reply-To: References: Message-ID: Matteo Mortari created DROOLS-1504: -------------------------------------- Summary: Resolution of variable with leading or trailing spaces Key: DROOLS-1504 URL: https://issues.jboss.org/browse/DROOLS-1504 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 04:10:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 31 Mar 2017 04:10:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-20) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387086#comment-13387086 ] Hayk Hovsepyan commented on HAWKULARQE-20: ------------------------------------------ Test case is: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10025 > Manual Testcases - Create and Run > --------------------------------- > > Key: HAWKULARQE-20 > URL: https://issues.jboss.org/browse/HAWKULARQE-20 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Labels: hawkular-qe-manual > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 04:27:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 31 Mar 2017 04:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-35) Manual Testcases - Create and Run In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan reassigned HAWKULARQE-35: ---------------------------------------- Assignee: Prachi Yadav (was: Vojtech Prusa) > Manual Testcases - Create and Run > --------------------------------- > > Key: HAWKULARQE-35 > URL: https://issues.jboss.org/browse/HAWKULARQE-35 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Prachi Yadav > Priority: Critical > > Add new provider with SSL and check that provider is added successfully and inventory is loaded. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 04:42:01 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 31 Mar 2017 04:42:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1047) CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK. In-Reply-To: References: Message-ID: Hynek ?v?bek created ELY-1047: --------------------------------- Summary: CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK. Key: ELY-1047 URL: https://issues.jboss.org/browse/ELY-1047 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek ?v?bek Assignee: Darran Lofthouse When I create credential store storage file under OracleJDK or OpenJDK and then I want to access to it under IBMJDK I get meaningless error message about this. I expect some error message about that you must use to access same JDK as was used for creation storage file. *How to reproduce* Create credential store storage file with OracleJDK (or openJDK) {code} java -jar wildfly-elytron-tool.jar credential-store --add moje --secret asdfasdf --location="PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary {code} Try to list aliases with IBMJDK {code} java -jar wildfly-elytron-tool.jar credential-store --aliases --location="/PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary ELY09526: Unable to initialize credential store {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 05:02:00 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 31 Mar 2017 05:02:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-82) JMAN4 Feature Requests Test Cases Review In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayk Hovsepyan resolved HAWKULARQE-82. -------------------------------------- Resolution: Done Done review for all in progress JMAN4 tasks. > JMAN4 Feature Requests Test Cases Review > ---------------------------------------- > > Key: HAWKULARQE-82 > URL: https://issues.jboss.org/browse/HAWKULARQE-82 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > Go through all JMAN4 Features and their QE tasks: > Make sure that all existing Polarion testcases are created and mentioned in QE tasks. > Review polarion testcases, make comments on QE tasks to fix testcases if necessary. > If testcases are missing, request to create them. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 05:43:00 2017 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Fri, 31 Mar 2017 05:43:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8455) Upgrade HAL to 2.9.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-8455: ------------------------------ Fix Version/s: 11.0.0.CR1 (was: 11.0.0.Beta1) > Upgrade HAL to 2.9.6.Final > -------------------------- > > Key: WFLY-8455 > URL: https://issues.jboss.org/browse/WFLY-8455 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 11.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 06:28:00 2017 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Fri, 31 Mar 2017 06:28:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2607) (7.1.x) Upgrade undertow from 1.4.11.Final to 1.4.12.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved JBEAP-10053 to WFCORE-2607: ------------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2607 (was: JBEAP-10053) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Web (Undertow)) > (7.1.x) Upgrade undertow from 1.4.11.Final to 1.4.12.Final > ---------------------------------------------------------- > > Key: WFCORE-2607 > URL: https://issues.jboss.org/browse/WFCORE-2607 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 06:54:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 31 Mar 2017 06:54:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8482) ObjectStoreTypeTestCase fails intermittently on IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky moved JBEAP-10054 to WFLY-8482: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8482 (was: JBEAP-10054) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.1.0.DR10) (was: 7.1.0.DR11) (was: 7.1.0.DR13) > ObjectStoreTypeTestCase fails intermittently on IPv6 > ---------------------------------------------------- > > Key: WFLY-8482 > URL: https://issues.jboss.org/browse/WFLY-8482 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > *Description of problem:* > ObjectStoreTypeTestCase fails intermittently on IPv6. This test is *not* from wf-core. > *How reproducible:* > * 5% > * this issue is more common on pure IPv6 machines with IBM JDK > *Actual results:* > Maven logs: > {noformat} > 12:52:47 Running org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > 12:55:18 Tests run: 5, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 151.197 sec <<< FAILURE! - in org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > 12:55:18 testJdbcObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 38.363 sec <<< FAILURE! > 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > 12:55:18 at org.junit.Assert.fail(Assert.java:88) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) > 12:55:18 > 12:55:18 testJournalObjectStore(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 29.533 sec <<< FAILURE! > 12:55:18 org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> > 12:55:18 at org.junit.Assert.assertEquals(Assert.java:115) > 12:55:18 at org.junit.Assert.assertEquals(Assert.java:144) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) > 12:55:18 > 12:55:18 testUseJdbcStoreWithoutDatasource(org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase) Time elapsed: 27.734 sec <<< FAILURE! > 12:55:18 java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > 12:55:18 (\"subsystem\" => \"datasources\"), > 12:55:18 (\"data-source\" => \"ObjectStoreTestDS\") > 12:55:18 ]"}} > 12:55:18 at org.junit.Assert.fail(Assert.java:88) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > 12:55:18 at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) > 12:55:18 at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line 'data-source remove --name=ObjectStoreTestDS': org.jboss.as.cli.CommandFormatException: The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.removeDataSource(ObjectStoreTypeTestCase.java:261) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJdbcObjectStore(ObjectStoreTypeTestCase.java:140) > {noformat} > Standard output: > {noformat} > 12:52:47,276 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:52:47,545 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:52:47,560 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > 12:52:48,082 INFO [org.jboss.remoting] (main) JBoss Remoting version 5.0.0.Beta12-redhat-1 > 12:52:48,164 INFO [org.xnio] (main) XNIO version 3.4.3.Final-redhat-1 > 12:52:48,287 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > 12:52:49,068 INFO [org.wildfly.security] (main) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m12:52:51,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:52:53,468 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:52:54,015 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:52:54,668 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:52:59,007 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:52:59,191 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 10) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:00,425 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:00,462 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:00,507 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:00,832 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:00,925 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:53:00,931 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:01,147 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:53:01,159 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:53:01,209 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:01,309 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:01,317 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[33m12:53:01,454 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:01,512 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:01,545 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:01,733 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:01,801 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:53:02,025 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:02,027 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:02,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:02,479 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:02,833 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:02,834 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:03,020 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:03,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:03,091 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:03,447 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:03,696 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:03,723 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:03,772 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:04,334 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:04,335 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:04,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:05,306 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:05,331 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:05,575 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:05,581 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:05,883 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:53:08,210 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:08,212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 19241ms - Started 351 of 670 services (471 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:08,215 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:14,504 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:53:15,001 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > &#27;[0m12:53:15,570 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m12:53:16,773 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:17,319 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > &#27;[0m12:53:17,429 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:17,430 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:17,433 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:17,439 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:17,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:17,511 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:17,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:17,514 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:17,515 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:17,426 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:17,572 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:17,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:17,623 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:17,672 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:17,870 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:18,039 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 696ms > &#27;[0m&#27;[0m12:53:18,042 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:53:19,098 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:19,281 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:20,041 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:20,160 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:20,219 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:20,196 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:20,274 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:20,282 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:20,306 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:20,314 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:20,329 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:20,344 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[33m12:53:20,348 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:20,359 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:53:20,579 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:20,606 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:20,608 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:20,613 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:20,642 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:20,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:20,646 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:20,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:20,759 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:20,769 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:20,773 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:20,768 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:20,843 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:21,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:22,444 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:22,447 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:22,448 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:22,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:22,479 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[33m12:53:23,156 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getWrappedConnection(BaseWrapperManagedConnection.java:1203) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.getConnection(BaseWrapperManagedConnection.java:462) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.openConnection(XAResourceRecoveryImpl.java:438) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:199) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) > ... 10 more > &#27;[0m&#27;[33m12:53:23,161 WARN [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$WildFlyXaMCF] (Periodic Recovery) IJ030000: Unable to load connection listener: IJ031002: Error during loading connection listener plugin: javax.resource.ResourceException: IJ031002: Error during loading connection listener plugin > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:929) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:978) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:563) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541) > at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298) > at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.jboss.jca.core.recovery.DefaultRecoveryPlugin.close(DefaultRecoveryPlugin.java:107) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.closeConnection(XAResourceRecoveryImpl.java:469) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:212) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:545) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:184) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > Caused by: java.lang.ClassNotFoundException: org.jboss.as.test.manualmode.jca.connectionlistener.TestConnectionListener > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.loadConnectionListenerPlugin(BaseWrapperManagedConnectionFactory.java:923) > ... 17 more > &#27;[0m&#27;[0m12:53:23,749 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 4,5,management-handler-thread] > &#27;[0m&#27;[0m12:53:24,045 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:24,078 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:53:24,099 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:24,101 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 6053ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:24,326 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:53:24,382 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:53:24,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:24,572 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:24,574 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:24,765 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:24,828 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:24,857 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:24,859 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:24,860 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:24,965 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:24,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:24,972 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:24,973 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:24,978 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:25,073 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 492ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore* > StackTrace: > {noformat} > org.junit.ComparisonFailure: expected:<[default]> but was:<[jdbc]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testJournalObjectStore(ObjectStoreTypeTestCase.java:98) > {noformat} > Standard output: > {noformat} > 12:53:25,500 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:53:25,523 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:53:25,547 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > &#27;[0m12:53:28,442 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:53:31,091 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:53:31,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:53:32,467 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:53:37,670 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:37,965 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:53:40,066 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:53:40,279 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:40,364 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[33m12:53:40,699 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:53:40,791 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:53:40,824 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:53:40,920 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:53:40,941 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:53:41,430 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:53:41,485 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:53:41,489 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:53:41,508 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:53:41,678 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:53:41,691 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:53:41,701 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:53:41,905 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:53:41,912 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:53:41,909 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:53:42,064 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:53:42,159 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:53:42,659 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:43,061 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:53:43,209 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:53:43,362 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:53:43,363 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:53:44,187 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:44,206 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:44,213 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:44,295 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:53:44,304 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:53:46,834 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:46,835 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:46,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:46,989 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:53:47,003 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:53:47,005 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:53:47,364 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:48,055 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:53:50,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:53:50,640 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:53:50,641 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 24187ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:53:50,642 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m12:53:51,263 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:53:51,444 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "jdbc" > } > 12:53:51,506 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "jdbc" > } > 12:53:52,356 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:52,835 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,259 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,715 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > 12:53:53,775 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:53:53,803 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:53:53,873 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:53:54,090 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:53:54,152 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:53:54,154 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:53:54,346 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:53:54,414 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:53:54,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:53:54,539 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:53:54,601 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:53:54,627 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:53:54,536 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:53:54,630 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:53:54,633 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:53:54,665 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:53:54,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:53:54,738 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 533ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line 'data-source add --name=ObjectStoreTestDS --jndi-name=java:jboss/datasources/ObjectStoreTestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --jta=false': org.jboss.as.cli.CommandLineException: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"datasources\"), > (\"data-source\" => \"ObjectStoreTestDS\") > ]"}} > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.createDataSource(ObjectStoreTypeTestCase.java:257) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testUseJdbcStoreWithoutDatasource(ObjectStoreTypeTestCase.java:151) > {noformat} > Standard output: > {noformat} > 12:53:54,968 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:53:54,976 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:53:54,996 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:192, -Dnode1=2620:52:0:105f::ffff:193, -Dmcast=ff0e:52:0:105f::ffff:195, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-11, -c=standalone-ha.xml] > &#27;[0m12:53:57,625 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta3-redhat-1 > &#27;[0m&#27;[0m12:54:00,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.Final-redhat-1 > &#27;[0m&#27;[0m12:54:00,857 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) starting > &#27;[0m&#27;[0m12:54:01,702 INFO [org.jboss.as.domain.management] (MSC service thread 1-2) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:54:06,509 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:54:06,719 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 22) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:54:08,905 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:54:09,017 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:09,056 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:09,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:54:09,652 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:54:09,658 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:54:09,699 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[33m12:54:09,791 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:54:09,859 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:54:09,918 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:54:10,021 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:54:10,083 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.0.Final-redhat-1) > &#27;[0m&#27;[0m12:54:10,150 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:54:10,161 INFO [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:54:10,371 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:54:10,372 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:54:10,449 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:54:10,938 INFO [org.wildfly.security] (MSC service thread 1-2) ELY00001: WildFly Elytron version 1.1.0.Beta18-redhat-1 > &#27;[0m&#27;[0m12:54:11,007 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:54:11,381 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:54:12,044 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:54:12,045 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:54:12,049 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:54:12,572 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:54:13,204 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:54:13,207 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:54:13,232 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:54:13,239 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0098: Bound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:54:13,246 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.3.Final-redhat-1 > &#27;[0m&#27;[0m12:54:13,290 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:195:23364 > &#27;[0m&#27;[0m12:54:13,573 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:54:13,608 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:54:13,614 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:54:14,914 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:54:15,209 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:54:15,212 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:54:15,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:54:16,087 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.6.Final-redhat-1 (Apache CXF 3.1.8.redhat-1) > &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:54:19,422 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:192]:9990/management > &#27;[0m&#27;[0m12:54:19,471 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:192]:9990 > &#27;[0m&#27;[0m12:54:19,472 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) started in 23779ms - Started 357 of 676 services (472 services are lazy, passive or on-demand) > &#27;[0m12:54:20,014 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:54:20,148 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:54:20,584 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:54:21,270 INFO [org.jboss.as.cli.CommandContext] (main) operation-requires-reload: true > process-state: reload-required > 12:54:21,342 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:54:21,433 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:54:21,498 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:54:21,698 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:54:21,775 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:54:21,777 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:54:21,976 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0099: Unbound non-transactional data source: java:jboss/datasources/ObjectStoreTestDS > &#27;[0m&#27;[0m12:54:22,019 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:54:22,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:54:22,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:54:22,166 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:54:22,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:192]:8009 > &#27;[0m&#27;[0m12:54:22,173 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:192]:8443 > &#27;[0m&#27;[0m12:54:22,180 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:54:22,246 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:54:22,247 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:192]:8080 > &#27;[0m&#27;[0m12:54:22,323 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:54:22,428 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha17-redhat-1) stopped in 611ms > &#27;[0m > {noformat} > *org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore* > StackTrace: > {noformat} > java.lang.AssertionError: Failed to execute line '/subsystem=transactions/log-store=log-store:read-attribute(name=type)': org.jboss.as.cli.CommandFormatException: No connection to the controller. > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:166) > at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.readObjectStoreType(ObjectStoreTypeTestCase.java:265) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:275) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.setDefaultObjectStore(ObjectStoreTypeTestCase.java:271) > at org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase.testHornetQObjectStore(ObjectStoreTypeTestCase.java:89) > {noformat} > Standard output: > {noformat} > 12:03:49,027 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance > 12:03:49,033 WARNING [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Bundles path is deprecated and no longer used. > 12:03:49,036 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/amd64/ibm-java-80/bin/java, -D[Standalone], -Dorg.jboss.ejb.client.wildfly-testsuite-hack=true, -Xmx512m, -XX:MetaspaceSize=128m, -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -server, -Dts.timeout.factor=100, -Dnode0=2620:52:0:105f::ffff:196, -Dnode1=2620:52:0:105f::ffff:197, -Dmcast=ff0e:52:0:105f::ffff:199, -Dmcast.ttl=0, -Djbossas.ts.submodule.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/../../.., -Djava.io.tmpdir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target, -Djboss.inst=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log/server.log, -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -jar, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/jboss-eap-7.1/modules:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/modules, org.jboss.as.standalone, -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas, -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone, -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/log, -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration, -Dts.wildfly.version=7.1.0.Alpha1-redhat-12, -c=standalone-ha.xml] > &#27;[0m12:03:50,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1 > &#27;[0m&#27;[0m12:03:53,752 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1 > &#27;[0m&#27;[0m12:03:54,152 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting > &#27;[0m&#27;[0m12:03:54,774 INFO [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider > &#27;[0m&#27;[0m12:03:59,746 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:03:59,994 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1 > &#27;[0m&#27;[0m12:03:59,996 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 6) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 > &#27;[0m&#27;[0m12:04:00,083 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 28) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:01,997 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:04:02,081 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:04:02,112 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1 > &#27;[0m&#27;[0m12:04:02,472 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:04:02,526 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[33m12:04:02,569 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:04:02,942 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 49) WFLYJSF0007: Activated the following JSF Implementations: [main] > &#27;[0m&#27;[0m12:04:02,994 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:04:03,030 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:04:03,072 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:04:03,084 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:04:03,094 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[0m12:04:03,134 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.0.Beta12-redhat-1 > &#27;[0m&#27;[0m12:04:03,602 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:04:03,688 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) > &#27;[0m&#27;[0m12:04:04,386 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:04:04,555 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:04,556 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:04:04,628 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:04:04,804 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:04:04,871 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:04:04,899 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:05,546 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:04:06,048 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:06,116 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:04:06,279 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 > &#27;[0m&#27;[0m12:04:06,302 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:06,494 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 > &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:06,714 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:06,813 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:07,765 INFO [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:04:07,962 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:04:07,965 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:04:08,245 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:08,821 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) > &#27;[0m&#27;[0m12:04:11,110 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:04:11,146 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management > &#27;[0m&#27;[0m12:04:11,148 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 > &#27;[0m&#27;[0m12:04:11,149 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 21534ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) > &#27;[0m12:04:11,579 INFO [org.jboss.as.cli.CommandContext] (main) Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions. > 12:04:11,637 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "result" => "default" > } > 12:04:12,297 INFO [org.jboss.as.cli.CommandContext] (main) { > "outcome" => "success", > "response-headers" => { > "operation-requires-restart" => true, > "process-state" => "restart-required" > } > } > &#27;[0m12:04:12,438 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:12,439 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:12,459 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:12,466 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:04:12,473 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:04:12,474 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:12,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:04:12,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:12,491 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:04:12,550 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:12,676 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:04:12,678 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:12,688 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:04:12,936 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:12,984 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 670ms > &#27;[0m&#27;[0m12:04:12,988 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) starting > &#27;[0m&#27;[0m12:04:14,141 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:14,319 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 14) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21-redhat-1, Subsystem Version=1.0.0.Beta2 > &#27;[0m&#27;[0m12:04:14,346 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > &#27;[0m&#27;[0m12:04:14,928 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &#27;[0m&#27;[0m12:04:15,085 INFO [org.jboss.as.security] (ServerService Thread Pool -- 60) WFLYSEC0002: Activating Security Subsystem > &#27;[0m&#27;[0m12:04:15,088 INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.0.Alpha3-redhat-1 > &#27;[0m&#27;[33m12:04:15,097 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 62) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > &#27;[0m&#27;[0m12:04:15,123 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) WFLYCLJG0001: Activating JGroups subsystem. > &#27;[0m&#27;[0m12:04:15,155 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > &#27;[0m&#27;[0m12:04:15,161 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 64) WFLYWS0002: Activating WebServices Extension > &#27;[0m&#27;[0m12:04:15,176 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors > &#27;[0m&#27;[0m12:04:15,211 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 42) WFLYCLINF0001: Activating Infinispan subsystem. > &#27;[0m&#27;[0m12:04:15,237 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.1.Final) > &#27;[0m&#27;[0m12:04:15,241 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.4.8.Final-redhat-1 starting > &#27;[0m&#27;[0m12:04:15,306 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service > &#27;[0m&#27;[0m12:04:15,345 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. > &#27;[0m&#27;[0m12:04:15,347 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. > &#27;[0m&#27;[0m12:04:15,268 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0014: Creating file handler for path '/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]'] > &#27;[0m&#27;[0m12:04:15,674 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > &#27;[0m&#27;[0m12:04:15,675 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. > &#27;[0m&#27;[0m12:04:15,701 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:15,702 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > &#27;[0m&#27;[0m12:04:15,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:15,826 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000001: Initializing mod_cluster version 1.3.6.CR1 > &#27;[0m&#27;[0m12:04:15,831 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:52:0:105f:0:0:ffff:199:23364 > &#27;[0m&#27;[0m12:04:15,896 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 37) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > &#27;[0m&#27;[0m12:04:15,929 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:16,002 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:16,006 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:15,937 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:16,815 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none > &#27;[0m&#27;[33m12:04:16,852 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &#27;[0m&#27;[0m12:04:16,854 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-ipv6/1d07701d/testsuite/integration/manualmode/target/jbossas/standalone/deployments > &#27;[0m&#27;[0m12:04:16,892 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:16,895 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.1.7.Final (Apache CXF 3.1.9) > &#27;[0m12:04:18,708 INFO [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance > &#27;[0m12:04:18,760 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[2620:52:0:105f::ffff:196]:9990/management > &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[2620:52:0:105f::ffff:196]:9990 > &#27;[0m&#27;[0m12:04:18,762 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 5768ms - Started 376 of 695 services (475 services are lazy, passive or on-demand) > &#27;[0m&#27;[0m12:04:18,767 INFO [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0212: Resuming server > &#27;[0m&#27;[0m12:04:18,906 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0236: Suspending server with no timeout. > &#27;[0m&#27;[0m12:04:18,964 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &#27;[0m&#27;[0m12:04:19,116 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &#27;[0m&#27;[0m12:04:19,139 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatXaDS] > &#27;[0m&#27;[0m12:04:19,140 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/StatDS] > &#27;[0m&#27;[0m12:04:19,236 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping > &#27;[0m&#27;[0m12:04:19,244 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown > &#27;[0m&#27;[0m12:04:19,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow AJP listener ajp suspending > &#27;[0m&#27;[0m12:04:19,369 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [2620:52:0:105f::ffff:196]:8009 > &#27;[0m&#27;[0m12:04:19,370 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTPS listener https suspending > &#27;[0m&#27;[0m12:04:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [2620:52:0:105f::ffff:196]:8443 > &#27;[0m&#27;[0m12:04:19,421 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &#27;[0m&#27;[0m12:04:19,480 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HTTP listener default suspending > &#27;[0m&#27;[0m12:04:19,481 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [2620:52:0:105f::ffff:196]:8080 > &#27;[0m&#27;[0m12:04:19,483 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > &#27;[0m&#27;[0m12:04:19,562 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) stopped in 375ms > &#27;[0m > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 07:33:00 2017 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Fri, 31 Mar 2017 07:33:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2385) There are two different error messages for adding duplicate record to CS by same command. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov reassigned WFCORE-2385: ------------------------------------- Assignee: Michal Petrov (was: Peter Skopek) > There are two different error messages for adding duplicate record to CS by same command. > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2385 > URL: https://issues.jboss.org/browse/WFCORE-2385 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Michal Petrov > > There are two different error messages for adding duplicate record to CS by same command. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/customcredCS007.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret) > {code} > And now we try add there same alias with exactly same name and with name in uppercase > {code} > /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"elytron\"), > (\"credential-store\" => \"cs007\"), > (\"alias\" => \"alias001\") > ]", > "rolled-back" => true > } > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=ALIAS001:add(secret-value=secret) > { > "outcome" => "failed", > "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store", > "rolled-back" => true > } > {code} > You can see different error message. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 07:37:00 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 31 Mar 2017 07:37:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7738) XTS suspend tests fail with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Studensky updated WFLY-7738: -------------------------------- Comment: was deleted (was: Actual fix for this issue will be similar to WFLY-6192 once it is reviewed.) > XTS suspend tests fail with security manager > -------------------------------------------- > > Key: WFLY-7738 > URL: https://issues.jboss.org/browse/WFLY-7738 > Project: WildFly > Issue Type: Bug > Components: Test Suite, Web Services, XTS > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=AtomicTransactionSuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-5) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsat.AtomicTransactionExecutionService.init(AtomicTransactionExecutionService.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} > *org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BusinessActivitySuspendTestCase -Dsecurity.manager}} > {noformat} > WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-3) Application {org.jboss.as.test.xts.suspend}ExecutorService#{http://suspend.xts.test.as.jboss.org/}init has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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: javax.xml.ws.WebServiceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" from Service Module Loader") > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:72) > at javax.xml.ws.spi.Provider.provider(Provider.java:113) > at javax.xml.ws.Service.(Service.java:57) > at javax.xml.ws.Service.create(Service.java:687) > at org.jboss.as.test.xts.suspend.Helpers.getRemoteService(Helpers.java:45) > at org.jboss.as.test.xts.suspend.wsba.BusinessActivityExecutionService.init(BusinessActivityExecutionService.java:76) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:137) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 61 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/executorService.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.executorService.war:main" 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.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.Thread.getContextClassLoader(Thread.java:1440) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:70) > ... 95 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 07:40:00 2017 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Fri, 31 Mar 2017 07:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2371) Unable to create custom credentail security factory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina reassigned WFCORE-2371: ---------------------------------- Assignee: Jan Kalina (was: Dmitrii Tikhomirov) > Unable to create custom credentail security factory > --------------------------------------------------- > > Key: WFCORE-2371 > URL: https://issues.jboss.org/browse/WFCORE-2371 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > When I try to register custom credential security factory I get {{NoClassDefFoundError}} > {code} > 06:54:49,166 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.wildfly.extras.creaper.commands.elytron.credfactory.AddCustomCredentialSecurityFactoryImpl in Module "org.jboss.customcredsecfacimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/credfactory/AddCustomCredentialSecurityFactoryImpl (Module "org.jboss.customcredsecfacimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/CredentialSecurityFactory > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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) > 06:54:49,167 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory: org.jboss.msc.service.StartException in service org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > 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.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/credfactory/AddCustomCredentialSecurityFactoryImpl (Module "org.jboss.customcredsecfacimpl" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/CredentialSecurityFactory > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:448) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79) > at org.jboss.modules.Module.loadModuleClass(Module.java:708) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.createValue(CustomComponentDefinition.java:156) > at org.wildfly.extension.elytron.CustomComponentDefinition$ComponentAddHandler.lambda$performRuntime$1(CustomComponentDefinition.java:135) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > 06:54:49,168 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("custom-credential-security-factory" => "CreaperTestAddCustomCredentialSecurityFactory") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory: Failed to start service > Caused by: java.lang.NoClassDefFoundError: Failed to link org/wildfly/extras/creaper/commands/elytron/credfactory/AddCustomCredentialSecurityFactoryImpl (Module \"org.jboss.customcredsecfacimpl\" from local module loader @282ba1e (finder: local module finder @13b6d03 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR12/jboss-eap-7.1/modules/system/layers/base))): org/wildfly/extension/elytron/capabilities/CredentialSecurityFactory"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-factory.credential.CreaperTestAddCustomCredentialSecurityFactory"] > } > {code} > That works in DR11 without issue > Here is implementation of custom credential security factory > {code:java|title=AddCustomCredentialSecurityFactoryImpl.java} > package org.wildfly.extras.creaper.commands.elytron.credfactory; > import java.security.GeneralSecurityException; > import java.util.Map; > import org.wildfly.extension.elytron.Configurable; > import org.wildfly.extension.elytron.capabilities.CredentialSecurityFactory; > import org.wildfly.security.credential.Credential; > public class AddCustomCredentialSecurityFactoryImpl implements CredentialSecurityFactory, Configurable { > @Override > public Credential create() throws GeneralSecurityException { > return null; > } > @Override > public void initialize(Map configuration) { > if (configuration.containsKey("throwException")) { > throw new IllegalStateException("Only test purpose. This exception was thrown on demand."); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 07:53:00 2017 From: issues at jboss.org (Jean-Francois Denise (JIRA)) Date: Fri, 31 Mar 2017 07:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387260#comment-13387260 ] Jean-Francois Denise commented on WFCORE-2283: ---------------------------------------------- WFCORE-2599 is very visible in this context. > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone at localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:13:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:13:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2471) Elytron kerberos-security-factory debug attribute type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-2471. -------------------------------- Resolution: Done [~dlofthouse] I think this is done so I am resolving this. At least the linked JBEAP issue was incorporated by the core upgrade > Elytron kerberos-security-factory debug attribute type > ------------------------------------------------------ > > Key: WFCORE-2471 > URL: https://issues.jboss.org/browse/WFCORE-2471 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 3.0.0.Beta12 > > > Currently kerberos-security-factory debug attribute is in management model defined as STRING type, but could be BOOLEAN. > {code} > "kerberos-security-factory" => { > "description" => "A security factory for obtaining a GSSCredential for use during authentication.", > "model-description" => {"*" => { > "description" => "A security factory for obtaining a GSSCredential for use during authentication.", > "capabilities" => [{ > "name" => "org.wildfly.security.security-factory.credential", > "dynamic" => true > }], > "attributes" => { > "debug" => { > "type" => STRING, > "description" => "Should the JAAS step of obtaining the credential have debug logging enabled.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > In XSD it is properly configured as boolean > {code:xml} > > > > Should the JAAS step of obtaining the credential have debug logging enabled. > > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:13:01 2017 From: issues at jboss.org (Ivo Studensky (JIRA)) Date: Fri, 31 Mar 2017 08:13:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-7595) JaxrsJacksonProviderTestCase fails with security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387279#comment-13387279 ] Ivo Studensky commented on WFLY-7595: ------------------------------------- It is caused by https://github.com/FasterXML/jackson-databind/pull/1585 > JaxrsJacksonProviderTestCase fails with security manager > -------------------------------------------------------- > > Key: WFLY-7595 > URL: https://issues.jboss.org/browse/WFLY-7595 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: Ivo Studensky > > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testDurationJsr310* > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testDurationJsrjdk8* > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testJacksonWithJsonIgnore* > *org.jboss.as.test.integration.jaxrs.jackson.JaxrsJacksonProviderTestCase#testSimpleJacksonResource* > {{./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dts.noSmoke -Dtest=JaxrsJacksonProviderTestCase -Dsecurity.manager}} > {code} > ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /jaxrsnoap/myjaxrs/country: java.lang.RuntimeException: RESTEASY003920: Unable to instantiate ContextResolver > at org.jboss.resteasy.spi.ResteasyProviderFactory.processProviderContracts(ResteasyProviderFactory.java:1480) > at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1304) > at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1256) > at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1178) > at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:601) > at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:377) > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:252) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250) > at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:171) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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.lang.RuntimeException: RESTEASY003325: Failed to construct public org.jboss.as.test.integration.jaxrs.jackson.JacksonProducer() throws java.lang.Exception > at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) > at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:1964) > at org.jboss.resteasy.spi.ResteasyProviderFactory.addContextResolver(ResteasyProviderFactory.java:1019) > at org.jboss.resteasy.spi.ResteasyProviderFactory.processProviderContracts(ResteasyProviderFactory.java:1474) > ... 52 more > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/opt/jboss-eap/src/7.1/jboss-eap-7.1.0.DR8/dist/target/jboss-eap-7.1/modules/system/layers/base/com/fasterxml/jackson/datatype/jackson-datatype-jdk8/main/jackson-datatype-jdk8-2.8.3.redhat-1.jar" "read")" in code source "(vfs:/content/jaxrsnoap.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.jaxrsnoap.war:main" 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.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350) > at java.util.zip.ZipFile.(ZipFile.java:210) > at java.util.zip.ZipFile.(ZipFile.java:149) > at java.util.jar.JarFile.(JarFile.java:166) > at java.util.jar.JarFile.(JarFile.java:103) > at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) > at java.net.URL.openStream(URL.java:1045) > at java.util.ServiceLoader.parse(ServiceLoader.java:304) > at java.util.ServiceLoader.access$200(ServiceLoader.java:185) > at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357) > at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398) > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > at com.fasterxml.jackson.databind.ObjectMapper.findModules(ObjectMapper.java:963) > at com.fasterxml.jackson.databind.ObjectMapper.findModules(ObjectMapper.java:946) > at com.fasterxml.jackson.databind.ObjectMapper.findAndRegisterModules(ObjectMapper.java:982) > at org.jboss.as.test.integration.jaxrs.jackson.JacksonProducer.(JacksonProducer.java:44) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > ... 55 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:14:01 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:14:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2438) Legacy Kerberos for management interface returns 500 instead of 401 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-2438. -------------------------------- Resolution: Done [~dlofthouse] The linked JBEAP was incorporated by the core release, so I am assuming this is done as well > Legacy Kerberos for management interface returns 500 instead of 401 > ------------------------------------------------------------------- > > Key: WFCORE-2438 > URL: https://issues.jboss.org/browse/WFCORE-2438 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta12 > > > On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case. > Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages > {code:title=server.log} > 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:16:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Fri, 31 Mar 2017 08:16:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1047) CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned ELY-1047: ---------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK. > ------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1047 > URL: https://issues.jboss.org/browse/ELY-1047 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > When I create credential store storage file under OracleJDK or OpenJDK and then I want to access to it under IBMJDK I get meaningless error message about this. > I expect some error message about that you must use to access same JDK as was used for creation storage file. > *How to reproduce* > Create credential store storage file with OracleJDK (or openJDK) > {code} > java -jar wildfly-elytron-tool.jar credential-store --add moje --secret asdfasdf --location="PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary > {code} > Try to list aliases with IBMJDK > {code} > java -jar wildfly-elytron-tool.jar credential-store --aliases --location="/PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary > ELY09526: Unable to initialize credential store > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:17:01 2017 From: issues at jboss.org (Ilia Vassilev (JIRA)) Date: Fri, 31 Mar 2017 08:17:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1037) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilia Vassilev reassigned ELY-1037: ---------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1037 > URL: https://issues.jboss.org/browse/ELY-1037 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > Without --location parameter a credential store storage file isn't saved (or save as is expected). > It pass but I am not able find credential store storage file on disk. > {code} > [hsvabek at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > It pass with this URI value and I am able to find credential store storage file on disk. > {code} > uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" > {code} > I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha3/src/main/java/org/wildfly/security/tool/CredentialStoreCommand.java#L238 > (test.store is interpreded as hostname in URI in first case) > *NOTE* > Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. > Behaviour must be consistent! -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:18:00 2017 From: issues at jboss.org (ehsavoie Hugonnet (JIRA)) Date: Fri, 31 Mar 2017 08:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2608) /deployment-overlay=test:redeploy-links doesn't work in mixed domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ehsavoie Hugonnet moved JBEAP-10057 to WFCORE-2608: --------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2608 (was: JBEAP-10057) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: 3.0.0.Beta11 (was: 7.1.0.DR15) > /deployment-overlay=test:redeploy-links doesn't work in mixed domain > -------------------------------------------------------------------- > > Key: WFCORE-2608 > URL: https://issues.jboss.org/browse/WFCORE-2608 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > {noformat} > [domain at localhost:9990 /] /deployment-overlay=test:redeploy-links(deployments=[simple-jsp.war]) > { > "outcome" => "failed", > "failure-description" => {"host-failure-descriptions" => {"msimka-t450.brq.redhat.com" => "JBAS014884: No operation named 'redeploy-links' exists at address [(\"deployment-overlay\" => \"test\")]"}}, > "rolled-back" => true, > "result" => {} > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:18:00 2017 From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=) Date: Fri, 31 Mar 2017 08:18:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (ELY-1047) CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hynek ?v?bek updated ELY-1047: ------------------------------ Component/s: Command-Line Tool > CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK. > ------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1047 > URL: https://issues.jboss.org/browse/ELY-1047 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Reporter: Hynek ?v?bek > Assignee: Ilia Vassilev > > When I create credential store storage file under OracleJDK or OpenJDK and then I want to access to it under IBMJDK I get meaningless error message about this. > I expect some error message about that you must use to access same JDK as was used for creation storage file. > *How to reproduce* > Create credential store storage file with OracleJDK (or openJDK) > {code} > java -jar wildfly-elytron-tool.jar credential-store --add moje --secret asdfasdf --location="PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary > {code} > Try to list aliases with IBMJDK > {code} > java -jar wildfly-elytron-tool.jar credential-store --aliases --location="/PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary > ELY09526: Unable to initialize credential store > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:25:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:25:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2606) Wildfly OpenSSL 1.0.0.CR1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-2606. -------------------------------- Fix Version/s: 3.0.0.Beta12 Resolution: Done > Wildfly OpenSSL 1.0.0.CR1 > ------------------------- > > Key: WFCORE-2606 > URL: https://issues.jboss.org/browse/WFCORE-2606 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:30:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:30:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2603) Upgrade WildFly Elytron Tool to 1.0.0.Beta1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-2603. -------------------------------- Resolution: Done > Upgrade WildFly Elytron Tool to 1.0.0.Beta1 > ------------------------------------------- > > Key: WFCORE-2603 > URL: https://issues.jboss.org/browse/WFCORE-2603 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:31:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:31:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2602) Upgrade WildFly Elytron to 1.1.0.Beta34 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-2602. -------------------------------- Resolution: Done [~dlofthouse] Assuming resolved since it was incorporated by the core upgrade > Upgrade WildFly Elytron to 1.1.0.Beta34 > --------------------------------------- > > Key: WFCORE-2602 > URL: https://issues.jboss.org/browse/WFCORE-2602 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:31:01 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:31:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2579) Rename WildFly Elytron Subsystem to wildfly-elytron-integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387312#comment-13387312 ] Kabir Khan commented on WFCORE-2579: ------------------------------------ [~dlofthouse] Assuming resolved since it was incorporated by the core upgrade > Rename WildFly Elytron Subsystem to wildfly-elytron-integration > --------------------------------------------------------------- > > Key: WFCORE-2579 > URL: https://issues.jboss.org/browse/WFCORE-2579 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta12 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:02 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2589: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Affects Versions: 3.0.0.Beta11 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 3.0.0.Beta13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:02 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2585) Servers in domain don't start if management interfaces are bound to all IPv4 addresses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2585: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Servers in domain don't start if management interfaces are bound to all IPv4 addresses > -------------------------------------------------------------------------------------- > > Key: WFCORE-2585 > URL: https://issues.jboss.org/browse/WFCORE-2585 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.0.Beta13 > > Attachments: host-controller.log, server-one.log > > > This is regression compared to EAP 7.0.0. > See attached logs server-one.log , host-controller.log > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2) MSC000001: Failed to start service jboss.server-boot-operations: org.jboss.msc.service.StartException in service jboss.server-boot-operations: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:72) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128) > at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110) > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68) > ... 4 more > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:426) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:241) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:427) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:415) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:177) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:113) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:02 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:02 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2578) Add ability to configure bind address for outbound XNIO connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2578: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Add ability to configure bind address for outbound XNIO connections > ------------------------------------------------------------------- > > Key: WFCORE-2578 > URL: https://issues.jboss.org/browse/WFCORE-2578 > Project: WildFly Core > Issue Type: Enhancement > Components: IO > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 3.0.0.Beta13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:03 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2574) Ensure wrap on server-ssl-context default to false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2574: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Ensure wrap on server-ssl-context default to false > -------------------------------------------------- > > Key: WFCORE-2574 > URL: https://issues.jboss.org/browse/WFCORE-2574 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:03 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2528) Clean up testsuite Elytron registration -- VaultPasswordsInCLITestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2528: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Clean up testsuite Elytron registration -- VaultPasswordsInCLITestCase > ---------------------------------------------------------------------- > > Key: WFCORE-2528 > URL: https://issues.jboss.org/browse/WFCORE-2528 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta13 > > > Leftover cleanup from WFCORE-1958 since VaultPasswordsInCLITestCase is not enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:03 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2521) TLS between domain and host controllers does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2521: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > TLS between domain and host controllers does not work > ----------------------------------------------------- > > Key: WFCORE-2521 > URL: https://issues.jboss.org/browse/WFCORE-2521 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: domain-management, domain-mode, eap71_alpha, regression, ssl > Fix For: 3.0.0.Beta13 > > > This is regression against EAP 7.0 . Customers relying on this feature won't be able to migrate to EAP 7.1. > Working configuration of TLS between domain and host controller from EAP 7.0 (legacy) does not work on EAP 7.1 anymore. > In server log there is this error: > {code:title=server.log} > [Host Controller] Caused by: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL > [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$StartTls.handleEvent(ClientConnectionOpenListener.java:527) > [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$StartTls.handleEvent(ClientConnectionOpenListener.java:477) > [Host Controller] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > [Host Controller] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > [Host Controller] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > [Host Controller] at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > [Host Controller] at ...asynchronous invocation...(Unknown Source) > [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466) > [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:437) > [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:430) > [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:163) > [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119) > [Host Controller] ... 9 more > {code} > See attached server.log for context log. > Tests in wildfly-core covering this scenario are currently ignored: > * SSLMasterSlaveOneWayTestCase is ignored by WFCORE-1978 > * SSLMasterSlaveTwoWayTestCase is ignored by WFCORE-2068 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:03 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2433) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2433: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2433 > URL: https://issues.jboss.org/browse/WFCORE-2433 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta13 > > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:04 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not validated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2317: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Nested attributes are not validated > ----------------------------------- > > Key: WFCORE-2317 > URL: https://issues.jboss.org/browse/WFCORE-2317 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha25 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 3.0.0.Beta13 > > > Attributes of type Object do not have their inner attributes validated for e.g. "requires" and "alternatives". -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:04 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2267: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2267 > URL: https://issues.jboss.org/browse/WFCORE-2267 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta13 > > > Only the Elytron realms are now used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:03 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:03 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2349: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. > --------------------------------------------------------------------------------- > > Key: WFCORE-2349 > URL: https://issues.jboss.org/browse/WFCORE-2349 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta13 > > > Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:04 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2136: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta13 > > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:04 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:04 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2101) Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2101: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2101 > URL: https://issues.jboss.org/browse/WFCORE-2101 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta13 > > > i.e. a later AS release will start to enable mechs like SCRAM, client should work without additional configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:05 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2100: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:05 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1960: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta13 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:05 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2016: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Change sasl-authentication-factor for management auth works after reload, but not after server restart > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2016 > URL: https://issues.jboss.org/browse/WFCORE-2016 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta13 > > > I can successfully configure a new sasl-authentication-factory and assign it to the management interface: > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"]) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper) > /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) > reload > {code} > after reload, i am forced to re-authenticate and it succeeds: > {code} > [standalone at localhost:9990 /] reload > Authenticating against security realm: exampleSaslRealm > Username: user1 > Password: > [standalone at localhost:9990 /] > {code} > Once i restart the server though and try to connect, i get a timeout: > {code} > $ ./jboss-cli.sh -c > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code} > It also fails if i force no local auth: > {code} > $ ./jboss-cli.sh -c --no-local-auth > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code}/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:05 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-2068: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2068 > URL: https://issues.jboss.org/browse/WFCORE-2068 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta13 > > > The listed test case is failing during clean up with the following error: - > {noformat} > java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80) > {noformat} > The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:05 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:05 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1944: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta13 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:06 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1649: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 3.0.0.Beta13 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:06 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once migrated to Remoting 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1897: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Follow up WFCORE-296 once migrated to Remoting 5 > ------------------------------------------------ > > Key: WFCORE-1897 > URL: https://issues.jboss.org/browse/WFCORE-1897 > Project: WildFly Core > Issue Type: Task > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta13 > > > WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:06 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1606: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta13 > > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:06 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1560: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh > -------------------------------------------------------------------------------- > > Key: WFCORE-1560 > URL: https://issues.jboss.org/browse/WFCORE-1560 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.8.Final > Environment: OS: CentOS 7.2 > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Wildfly-10.0.0-Final > Reporter: Michael Noack > Assignee: Ken Wills > Priority: Critical > Fix For: 3.0.0.Beta13 > > Attachments: JVM-DC.png, console-dc.log, host-controller.log, process-controller.log > > > When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am): > [root at dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)" > Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out > I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue. > Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:06 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:06 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1282: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta13 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:07 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1145: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron, domain-mode > Fix For: 3.0.0.Beta13 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:07 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-1059: ------------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta13 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:07 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-887: ------------------------------ Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta13 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:07 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-396: ------------------------------ Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta13 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:37:07 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Fri, 31 Mar 2017 08:37:07 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call non-published management API operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-13: ----------------------------- Fix Version/s: 3.0.0.Beta13 (was: 3.0.0.Beta12) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Beta13 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:45:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 31 Mar 2017 08:45:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387331#comment-13387331 ] Tomas Hofman commented on JBJCA-1338: ------------------------------------- Commit was rolled back due to this regression: https://issues.jboss.org/browse/JBEAP-9730 Some analysis: # The change I'd made set {{autocommit = true}} on the jdbc connection and reset the {{underlyingAutoCommit}} var in the {{BaseWrapperManagedConnection#cleanup()}} method: {code} BaseWrapperManagedConnection#cleanup(): jdbcAutoCommit = true; + if (jdbcAutoCommit != underlyingAutoCommit) + { + try { + con.setAutoCommit(jdbcAutoCommit); + underlyingAutoCommit = jdbcAutoCommit; + } catch (SQLException e) { + mcf.log.errorResettingAutoCommit(mcf.getJndiName(), e); + } + } {code} # That broke following fix in the {{destroy()}} method, which depended on {{underlyingAutoCommit}} var: {code} BaseWrapperManagedConnection#destroy(): // See JBAS-5678 if (!underlyingAutoCommit) con.rollback(); {code} so the connection was not rolled back on destroy caused by a connection error and the transaction somehow got committed. *But* that actually wasn't the reason why the test failed, as this fix is probably only relevant to Oracle db, which apparently commits a transaction when closing the connection (JBAS-5678). # The reason of the test failure is that postgresql driver commits a running transaction when autocommit is set to true: {code} PgConnection: public void setAutoCommit(boolean autoCommit) throws SQLException { checkClosed(); if (this.autoCommit == autoCommit) { return; } if (!this.autoCommit) { commit(); } this.autoCommit = autoCommit; } {code} # Also related - normally if a transaction is left open and a managed connection is closed, the transaction is closed in {{TxConnectionListener.tidyup()}}. That doesn't happen if the connection is closed due to connection error: {code} AbstractConnectionManager#returnManagedConnection(): if (!kill && cl.getState().equals(ConnectionState.NORMAL)) { cl.tidyup(); } {code} Possible solutions: # Continue with the old fix, just add {{con.rollback()}} before {{con.setAutoCommit(true)}} in the {{cleanup()}} method. # Rather then in the cleanup method, we could reset autocommit state in {{BaseWrapperManagedConnectionFactory#getInvalidConnections()}} just before validating the connection, where there should be no running transaction present... > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1338 > URL: https://issues.jboss.org/browse/JBJCA-1338 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.2.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:45:01 2017 From: issues at jboss.org (Hayk Hovsepyan (JIRA)) Date: Fri, 31 Mar 2017 08:45:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-1) [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387332#comment-13387332 ] Hayk Hovsepyan commented on HAWKULARQE-1: ----------------------------------------- Tested on upstream MiQ with EAP7 installed and manually configured from zip file. When immutable="true" it hides the menu operations from MiQ UI. Waiting for downstream productized version to test on. > [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-1 > URL: https://issues.jboss.org/browse/HAWKULARQE-1 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 08:49:00 2017 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 31 Mar 2017 08:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387335#comment-13387335 ] Tomas Hofman commented on JBJCA-1338: ------------------------------------- New PR with solution #2 from previous post: https://github.com/ironjacamar/ironjacamar/pull/623 > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1338 > URL: https://issues.jboss.org/browse/JBJCA-1338 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.2.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 09:15:00 2017 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Fri, 31 Mar 2017 09:15:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8483) Upgrade IronJacamar to 1.4.3 from 1.4.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri moved JBEAP-10059 to WFLY-8483: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8483 (was: JBEAP-10059) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) Fix Version/s: (was: 7.1.0.DR12) > Upgrade IronJacamar to 1.4.3 from 1.4.2 > --------------------------------------- > > Key: WFLY-8483 > URL: https://issues.jboss.org/browse/WFLY-8483 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > This is needed to adjust the SPI needed for the Elytron integration for the three JCA subsystems -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 09:27:00 2017 From: issues at jboss.org (David Hladky (JIRA)) Date: Fri, 31 Mar 2017 09:27:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8484) Dead Links In-Reply-To: References: Message-ID: David Hladky created WFLY-8484: ---------------------------------- Summary: Dead Links Key: WFLY-8484 URL: https://issues.jboss.org/browse/WFLY-8484 Project: WildFly Issue Type: Bug Components: Documentation Reporter: David Hladky Quoting [https://engineering.redhat.com/rt/Ticket/Display.html?id=442077] {quote} https://docs.jboss.org/author/display/WFLY8/Helloworld+quickstart https://docs.jboss.org/author/display/WFLY8/The+helloworld+example+in+depth have broken links Yan B. {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 09:52:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Fri, 31 Mar 2017 09:52:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-72) Polarion data cleanup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387382#comment-13387382 ] Sunil kondkar commented on HAWKULARQE-72: ----------------------------------------- -Some research on reports based on plans, added plans and child iterations in Polarion. https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans -Some maintenance on existing test runs, linked test runs to respective iterations in Polarion. -Reports can be generated now based on plans: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics?master_plan=MM-CFME-58 > Polarion data cleanup > --------------------- > > Key: HAWKULARQE-72 > URL: https://issues.jboss.org/browse/HAWKULARQE-72 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to able to have polarion reports in place. > Reports: > 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics > 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports > 3) Test Run Status by Plan > 4) Test Run Status by Plan and chosen fields > Tasks: > 1) Find and remove duplicates > 2) Each test case has correct fields > * Description > * Level > * Test type and sub type > * Automated or Manual > * Importance (Severity) > 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) > Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans > 4) Check if manual test cases are with approved status( Approve if needed) > 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. > (Need to check if we can have the polarion export job marking it Approved while executed going forward?) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 09:53:00 2017 From: issues at jboss.org (Sunil kondkar (JIRA)) Date: Fri, 31 Mar 2017 09:53:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-72) Polarion data cleanup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HAWKULARQE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunil kondkar resolved HAWKULARQE-72. ------------------------------------- Resolution: Done > Polarion data cleanup > --------------------- > > Key: HAWKULARQE-72 > URL: https://issues.jboss.org/browse/HAWKULARQE-72 > Project: Hawkular QE > Issue Type: Task > Reporter: Sunil kondkar > Assignee: Sunil kondkar > > Task to able to have polarion reports in place. > Reports: > 1) PQI Metrics: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/PQI%20Metrics > 2) Standard Reports: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/wiki/Reports/Standard%20Reports > 3) Test Run Status by Plan > 4) Test Run Status by Plan and chosen fields > Tasks: > 1) Find and remove duplicates > 2) Each test case has correct fields > * Description > * Level > * Test type and sub type > * Automated or Manual > * Importance (Severity) > 3) Do we need to create a plan in below link? (Like EAP team has release plans created that are used in reports ' Test Run Status by Plan' and 'Test Run Status by Plan and chosen fields' ) > Link: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/plans > 4) Check if manual test cases are with approved status( Approve if needed) > 5) All automated tests (CF-UI test and CFME tests) - need to be changed to Approved from 'Draft' status. > (Need to check if we can have the polarion export job marking it Approved while executed going forward?) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 10:47:00 2017 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Fri, 31 Mar 2017 10:47:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2385) There are two different error messages for adding duplicate record to CS by same command. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov updated WFCORE-2385: ---------------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly-core/pull/113 (was: https://github.com/wildfly/wildfly-core/pull/2301) > There are two different error messages for adding duplicate record to CS by same command. > ----------------------------------------------------------------------------------------- > > Key: WFCORE-2385 > URL: https://issues.jboss.org/browse/WFCORE-2385 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek ?v?bek > Assignee: Michal Petrov > > There are two different error messages for adding duplicate record to CS by same command. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/customcredCS007.jceks?create.storage=true", credential-reference={clear-text=pass123}) > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret) > {code} > And now we try add there same alias with exactly same name and with name in uppercase > {code} > /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"elytron\"), > (\"credential-store\" => \"cs007\"), > (\"alias\" => \"alias001\") > ]", > "rolled-back" => true > } > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=ALIAS001:add(secret-value=secret) > { > "outcome" => "failed", > "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store", > "rolled-back" => true > } > {code} > You can see different error message. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 10:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 31 Mar 2017 10:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387413#comment-13387413 ] Brian Stansberry commented on WFCORE-1059: ------------------------------------------ [~pferraro] is this blocking anything needed for WF 11? If not I want to reschedule it to 4. > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta13 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 10:49:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 31 Mar 2017 10:49:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-1960: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 (was: 3.0.0.Beta13) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 4.0.0.Alpha1 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 13:36:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 31 Mar 2017 13:36:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8485) Upgrade Narayana to 5.5.6.Final In-Reply-To: References: Message-ID: Tom Jenkinson created WFLY-8485: ----------------------------------- Summary: Upgrade Narayana to 5.5.6.Final Key: WFLY-8485 URL: https://issues.jboss.org/browse/WFLY-8485 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 14:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 31 Mar 2017 14:36:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8486) Upgrade Narayana to 5.5.6.Final In-Reply-To: References: Message-ID: Tom Jenkinson created WFLY-8486: ----------------------------------- Summary: Upgrade Narayana to 5.5.6.Final Key: WFLY-8486 URL: https://issues.jboss.org/browse/WFLY-8486 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 14:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 31 Mar 2017 14:40:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8485) Upgrade Narayana to 5.5.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated WFLY-8485: -------------------------------- Description: https://issues.jboss.org/projects/JBTM/versions/12334093 https://github.com/jbosstm/narayana/compare/5.5.5.Final...5.5.6.Final > Upgrade Narayana to 5.5.6.Final > ------------------------------- > > Key: WFLY-8485 > URL: https://issues.jboss.org/browse/WFLY-8485 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > https://issues.jboss.org/projects/JBTM/versions/12334093 > https://github.com/jbosstm/narayana/compare/5.5.5.Final...5.5.6.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 14:51:00 2017 From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=) Date: Fri, 31 Mar 2017 14:51:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1505) Model cannot compile if an item definition is using another item definition that is define after it In-Reply-To: References: Message-ID: M?lanie Gauthier created DROOLS-1505: ---------------------------------------- Summary: Model cannot compile if an item definition is using another item definition that is define after it Key: DROOLS-1505 URL: https://issues.jboss.org/browse/DROOLS-1505 Project: Drools Issue Type: Bug Components: dmn engine Reporter: M?lanie Gauthier Assignee: Edson Tirelli Let's say you have "Item Definition 1" and "Item Definition 2" in that order in the XML file. If "Item Definition 1" has one of its component that is of type "Item Definition 2", it won't compile. If "Item Definition 2" uses "Item Definition 1" then it is fine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 15:07:00 2017 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Fri, 31 Mar 2017 15:07:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1505) Model cannot compile if an item definition is using another item definition that is define after it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli reassigned DROOLS-1505: ------------------------------------- Assignee: Matteo Mortari (was: Edson Tirelli) > Model cannot compile if an item definition is using another item definition that is define after it > --------------------------------------------------------------------------------------------------- > > Key: DROOLS-1505 > URL: https://issues.jboss.org/browse/DROOLS-1505 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: M?lanie Gauthier > Assignee: Matteo Mortari > > Let's say you have "Item Definition 1" and "Item Definition 2" in that order in the XML file. > If "Item Definition 1" has one of its component that is of type "Item Definition 2", it won't compile. > If "Item Definition 2" uses "Item Definition 1" then it is fine. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 18:06:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 31 Mar 2017 18:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8487) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved JBEAP-10066 to WFLY-8487: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8487 (was: JBEAP-10066) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering JCA JMS Mail Security Web (Undertow) (was: Domain Management) (was: Security) (was: User Experience) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR11) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFLY-8487 > URL: https://issues.jboss.org/browse/WFLY-8487 > Project: WildFly > Issue Type: Bug > Components: Clustering, JCA, JMS, Mail, Security, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > Priority: Critical > Labels: cli, credential-reference, eap71_beta, management-model > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 18:06:01 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 31 Mar 2017 18:06:01 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8487) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-8487: ----------------------------------- Priority: Major (was: Critical) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFLY-8487 > URL: https://issues.jboss.org/browse/WFLY-8487 > Project: WildFly > Issue Type: Bug > Components: Clustering, JCA, JMS, Mail, Security, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > Labels: cli, credential-reference, eap71_beta, management-model > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 31 18:08:00 2017 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 31 Mar 2017 18:08:00 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-8487) Autocomplete doesn't work properly in credential-reference.store attribute. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-8487: ----------------------------------- Description: The CredentialReference class in core was not handling capability references correctly with the 'store' field in CR attributes. WFCORE-2433 corrects that; this JIRA is to update WF full's use of the class to take advantage of the fix. (was: Autocomplete doesn't work properly in credential-reference attribute. I want to use autocomplete for credential-reference.store but it doesn't work. *How to reproduce* {code} /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store= {code} ) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFLY-8487 > URL: https://issues.jboss.org/browse/WFLY-8487 > Project: WildFly > Issue Type: Bug > Components: Clustering, JCA, JMS, Mail, Security, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Hynek ?v?bek > Assignee: Brian Stansberry > Labels: cli, credential-reference, eap71_beta, management-model > > The CredentialReference class in core was not handling capability references correctly with the 'store' field in CR attributes. WFCORE-2433 corrects that; this JIRA is to update WF full's use of the class to take advantage of the fix. -- This message was sent by Atlassian JIRA (v7.2.3#72005)
> > >
>
 
>
> 7 >
>
 
>
> > > >
>
>

Welcome to JBoss EAP 7

>

Your Red Hat JBoss Enterprise Application Platform is running.

>

> Administration Console | > Documentation | > Online User Groups
>

> To replace this page simply deploy your own war with / as its context path.
> To disable it, remove the "welcome-content" handler for location / in the undertow subsystem. >
>
> >